Why is it that with 32 bit compilation, int is 32 bits, but
apparently this convention is not followed in 64 bit compilation.

I have not installed the 64 bit compiler yet, but apparently

int len = parent.children.length+1;

provokes the following error

> acomp.d(782): Error: cannot implicitly convert expression (parent.children.length + 1LU) of type ulong to int

parent is just a straightforward array

What is size_t for 64 bit?

Steve

On Monday, 17 February 2014 at 07:15:20 UTC, Steve Teale wrote:
> Why is it that with 32 bit compilation, int is 32 bits, but
> apparently this convention is not followed in 64 bit compilation.
>
> I have not installed the 64 bit compiler yet, but apparently
>
> int len = parent.children.length+1;
>
> provokes the following error
>
>> acomp.d(782): Error: cannot implicitly convert expression (parent.children.length + 1LU) of type ulong to int
>
> parent is just a straightforward array
>
> What is size_t for 64 bit?
>
> Steve

Sorry parent.children is just a straightforward array

On Monday, 17 February 2014 at 07:15:20 UTC, Steve Teale wrote:
> Why is it that with 32 bit compilation, int is 32 bits, but
> apparently this convention is not followed in 64 bit compilation.
>
> I have not installed the 64 bit compiler yet, but apparently
>
> int len = parent.children.length+1;
>
> provokes the following error
>
>> acomp.d(782): Error: cannot implicitly convert expression (parent.children.length + 1LU) of type ulong to int
>
> parent is just a straightforward array
>
> What is size_t for 64 bit?
>
> Steve

it is equal to machine word size. 4 bytes on x86, 8 on x64.

but it looks like length is not size_t but ulong in which case you need explicit cast from larget to smaller type. check lenght signature

On 2/17/2014 4:23 PM, evilrat wrote:

>
> but it looks like length is not size_t but ulong in which case you need
> explicit cast from larget to smaller type. check lenght signature

size_t is an alias to ulong on 64-bit. Aliases tend to show up in error messages as the underlying type.

On 2/17/2014 4:15 PM, Steve Teale wrote:

> parent is just a straightforward array
>
> What is size_t for 64 bit?
>

It's ulong on 64-bit and uint on 32. size_t and ptrdiff_t are defined as aliases in object.d.

On Monday, 17 February 2014 at 07:17:06 UTC, Steve Teale wrote:

>> What is size_t for 64 bit?
>>
>> Steve
>
> Sorry parent.children is just a straightforward array

Sorry again - forget about it. I'd forgotten that D actually says int is 32 bits, and ulong is 64, and size_t for a 64 bit machine is obviously 64.

I'll just go through the code and either change int to ulong or use a cast.

;=(

On Monday, 17 February 2014 at 07:46:02 UTC, Steve Teale wrote:
> On Monday, 17 February 2014 at 07:17:06 UTC, Steve Teale wrote:
>
>>> What is size_t for 64 bit?
>>>
>>> Steve
>>
>> Sorry parent.children is just a straightforward array
>
> Sorry again - forget about it. I'd forgotten that D actually says int is 32 bits, and ulong is 64, and size_t for a 64 bit machine is obviously 64.
>
> I'll just go through the code and either change int to ulong or use a cast.
>
> ;=(

or use auto :)

On Monday, 17 February 2014 at 07:46:02 UTC, Steve Teale wrote:
> On Monday, 17 February 2014 at 07:17:06 UTC, Steve Teale wrote:
>
>>> What is size_t for 64 bit?
>>>
>>> Steve
>>
>> Sorry parent.children is just a straightforward array
>
> Sorry again - forget about it. I'd forgotten that D actually says int is 32 bits, and ulong is 64, and size_t for a 64 bit machine is obviously 64.
>
> I'll just go through the code and either change int to ulong or use a cast.
>
> ;=(

Rather than change it to int/ulong, just change it to 'size_t len = parent.children.length+1' (or auto instead of size_t). This way it's proper for both 32-bit and 64-bit and you don't need to worry about architecture. If you do need a signed version, you can use ptrdiff_t.

> Rather than change it to int/ulong, just change it to 'size_t len = parent.children.length+1' (or auto instead of size_t). This way it's proper for both 32-bit and 64-bit and you don't need to worry about architecture. If you do need a signed version, you can use ptrdiff_t.

Yup, that's what I did when my head returned to its usual postion ;=)