I'm attempting a 64 bit port of DWT and I'd like some feedback on API changes.

My initial preference was no changes to existing API in order to ease future updates from SWT proper. But of course that requires casts and I suspect they will bubble to the surface and be exposed to end-users of DWT.

So now I'm leaning towards API changes of this sort:

    /// Extension to String
    public int indexOf( in char[] str,
                        char searched,
                        int fromIndex ){cast(int)...cast(int)...}

becomes

    /// Extension to String
    public ptrdiff_t indexOf( in char[] str,
                              char searched,
                              ptrdiff_t fromIndex) {...}


This maintains sign compatibility with the original API but may require some changes to existing code. For example:

---
// Fails 64 bit, works 32 bit
int idx = indexOf("astring", 't', 1);

 // Works 64 bit, Fails 32 bit
long idx = indexOf("astring", 't', 1);

// Works 64 bit and 32 bit
auto idx = indexOf("astring", 't', 1);
----

Does anyone have an alternative preferred approach to portable 32/64 bit code?

One possibility is separate code bases for 32 and 64 bit, as per SWT proper. This is not my preference but I am happy to do it if people feel it would be better this way.


Cheers,
ed

On 2014-06-24 02:30, ed wrote:
> I'm attempting a 64 bit port of DWT and I'd like some feedback on API
> changes.
>
> My initial preference was no changes to existing API in order to ease
> future updates from SWT proper. But of course that requires casts and I
> suspect they will bubble to the surface and be exposed to end-users of DWT.
>
> So now I'm leaning towards API changes of this sort:
>
>      /// Extension to String
>      public int indexOf( in char[] str,
>                          char searched,
>                          int fromIndex ){cast(int)...cast(int)...}
>
> becomes
>
>      /// Extension to String
>      public ptrdiff_t indexOf( in char[] str,
>                                char searched,
>                                ptrdiff_t fromIndex) {...}
>
>
> This maintains sign compatibility with the original API but may require
> some changes to existing code. For example:
>
> ---
> // Fails 64 bit, works 32 bit
> int idx = indexOf("astring", 't', 1);
>
>   // Works 64 bit, Fails 32 bit
> long idx = indexOf("astring", 't', 1);
>
> // Works 64 bit and 32 bit
> auto idx = indexOf("astring", 't', 1);
> ----
>
> Does anyone have an alternative preferred approach to portable 32/64 bit
> code?

I usually try to think like this, in some kind of priority list:

1. Follow system/native libraries - Example of this is when a system library uses pointers then the SWT code will use an "int/long". In DWT I would use the original pointer type

2. Follow the original SWT code - We want to make porting of future versions of SWT as easy as possible

3. Do what's most appropriate in D

In this case I would use "size_t" because that is the native type D uses for array indexes. This is what I've done in the Cocoa port, it's ported to support both 32bit and 64bit form the start.

> One possibility is separate code bases for 32 and 64 bit, as per SWT
> proper. This is not my preference but I am happy to do it if people feel
> it would be better this way.

I think it should be only one code base. SWT is actually only one code base. They have a tool that converts between 32bit and 64bit. They make separate releases but the it's only one repository. But D has language support that will make this easier: "alias", "version" and so on.

-- 
/Jacob Carlborg

On Tuesday, 24 June 2014 at 00:30:58 UTC, ed wrote:
> I'm attempting a 64 bit port of DWT and I'd like some feedback on API changes.
>
> My initial preference was no changes to existing API in order to ease future updates from SWT proper. But of course that requires casts and I suspect they will bubble to the surface and be exposed to end-users of DWT.
>
> So now I'm leaning towards API changes of this sort:
>
>     /// Extension to String
>     public int indexOf( in char[] str,
>                         char searched,
>                         int fromIndex ){cast(int)...cast(int)...}
>
> becomes
>
>     /// Extension to String
>     public ptrdiff_t indexOf( in char[] str,
>                               char searched,
>                               ptrdiff_t fromIndex) {...}
>
>
> This maintains sign compatibility with the original API but may require some changes to existing code. For example:
>
> ---
> // Fails 64 bit, works 32 bit
> int idx = indexOf("astring", 't', 1);
>
>  // Works 64 bit, Fails 32 bit
> long idx = indexOf("astring", 't', 1);
>
> // Works 64 bit and 32 bit
> auto idx = indexOf("astring", 't', 1);
> ----
>
> Does anyone have an alternative preferred approach to portable 32/64 bit code?
>
> One possibility is separate code bases for 32 and 64 bit, as per SWT proper. This is not my preference but I am happy to do it if people feel it would be better this way.
>
>
> Cheers,
> ed

Hi ed,

How is this going?  Where is the source code?  Would you like some help?

Mike

On Tuesday, 24 June 2014 at 19:06:34 UTC, Jacob Carlborg wrote:

> I think it should be only one code base. SWT is actually only one code base. They have a tool that converts between 32bit and 64bit.

Where can one obtain this tool and, hopefully, its source code?

Mike

On 2014-07-19 00:23, Mike wrote:

> Where can one obtain this tool and, hopefully, its source code?

Hmm, it might be this one [1]. Source code is somewhere here [2]. As far as I remember it didn't really do any interesting. Mostly converting between "long" and "int".

[1] http://www.eclipse.org/swt/jnigen.php
[2] http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt.tools

-- 
/Jacob Carlborg

On Saturday, 19 July 2014 at 14:55:29 UTC, Jacob Carlborg wrote:
> On 2014-07-19 00:23, Mike wrote:
>
>> Where can one obtain this tool and, hopefully, its source code?
>
> Hmm, it might be this one [1]. Source code is somewhere here [2]. As far as I remember it didn't really do any interesting. Mostly converting between "long" and "int".
>
> [1] http://www.eclipse.org/swt/jnigen.php
> [2] http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt.tools

It looks like it's here:

http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt.tools/src/org/eclipse/swt/tools/builders/Check64CompilationParticipant.java

Specifically, the `replace` function.  I guess I'll use that as a model.

Mike