Now that DMD has a 64-bit beta available, I'm working on getting a whole bunch of code to compile in 64 mode.  Frankly, the compiler is way too freakin' pedantic when it comes to implicit conversions (or lack thereof) of array.length.  99.999% of the time it's safe to assume an array is not going to be over 4 billion elements long.  I'd rather have a bug the 0.001% of the time than deal with the pedantic errors the rest of the time, because I think it would be less total time and effort invested.  To force me to either put casts in my code everywhere or change my entire codebase to use wider integers (with ripple effects just about everywhere) strikes me as purity winning out over practicality.

On Monday, February 14, 2011 15:22:38 dsimcha wrote:
> Now that DMD has a 64-bit beta available, I'm working on getting a whole bunch of code to compile in 64 mode.  Frankly, the compiler is way too freakin' pedantic when it comes to implicit conversions (or lack thereof) of array.length.  99.999% of the time it's safe to assume an array is not going to be over 4 billion elements long.  I'd rather have a bug the 0.001% of the time than deal with the pedantic errors the rest of the time, because I think it would be less total time and effort invested.  To force me to either put casts in my code everywhere or change my entire codebase to use wider integers (with ripple effects just about everywhere) strikes me as purity winning out over practicality.

I would have thought that you'd be using size_t when dealing with arrays, since that's what their length and indexing type is.

- Jonathan M Davis

dsimcha wrote:
> Now that DMD has a 64-bit beta available, I'm working on getting a whole bunch
> of code to compile in 64 mode.  Frankly, the compiler is way too freakin'
> pedantic when it comes to implicit conversions (or lack thereof) of
> array.length.  99.999% of the time it's safe to assume an array is not going
> to be over 4 billion elements long.  I'd rather have a bug the 0.001% of the
> time than deal with the pedantic errors the rest of the time, because I think
> it would be less total time and effort invested.  To force me to either put
> casts in my code everywhere or change my entire codebase to use wider integers
> (with ripple effects just about everywhere) strikes me as purity winning out
> over practicality.

We dealt with that in updating Phobos/Druntime to 64 bits. The end result was worth it (and yes, there would have been undiscovered bugs without those pedantic checks).

Most of the issues are solved if you use auto and foreach where possible, and size_t for the rest of the cases.

Here's something I've noticed (x86 code):

void main()
{
    ulong size = 2;
    int[] arr = new int[](size);
}

This will error with:
sizetTest.d(8): Error: cannot implicitly convert expression (size) of
type ulong to uint

size_t is aliased to uint since I'm running 32bit.

I'm really not experienced at all with 64bit, so I don't know if it's good to use uint explicitly (my hunch is that it's not good). uint as the array size wouldn't even compile in 64bit, right?

If I'm correct, wouldn't it be better if the error showed that it expects size_t which might be aliased to whatever type for a particular machine?

Andrej Mitrovic wrote:
> Here's something I've noticed (x86 code):
> 
> void main()
> {
>     ulong size = 2;
>     int[] arr = new int[](size);
> }
> 
> This will error with:
> sizetTest.d(8): Error: cannot implicitly convert expression (size) of
> type ulong to uint
> 
> size_t is aliased to uint since I'm running 32bit.
> 
> I'm really not experienced at all with 64bit, so I don't know if it's
> good to use uint explicitly (my hunch is that it's not good). uint as
> the array size wouldn't even compile in 64bit, right?

Use size_t for all array indices and sizes, and you'll be fine.


> If I'm correct, wouldn't it be better if the error showed that it
> expects size_t which might be aliased to whatever type for a
> particular machine?

The compiler doesn't actually know about size_t.

On Monday, February 14, 2011 16:30:09 Andrej Mitrovic wrote:
> Here's something I've noticed (x86 code):
> 
> void main()
> {
>     ulong size = 2;
>     int[] arr = new int[](size);
> }
> 
> This will error with:
> sizetTest.d(8): Error: cannot implicitly convert expression (size) of
> type ulong to uint
> 
> size_t is aliased to uint since I'm running 32bit.
> 
> I'm really not experienced at all with 64bit, so I don't know if it's good to use uint explicitly (my hunch is that it's not good). uint as the array size wouldn't even compile in 64bit, right?
> 
> If I'm correct, wouldn't it be better if the error showed that it expects size_t which might be aliased to whatever type for a particular machine?

Use size_t. It's the type which is used. It's aliased to whichever type is appropriate for the architecture. On 32 bits, that would be a 32 bit integer, so it's uint. On 64 bits, that would be a 64 bit integer, so it's ulong.

- Jonathan m Davis

auto, size_t, foreach & friends.

Once we get a stable 64bit compiler it's time to start advertising the portability of D apps across 32/64bit, methinks! ;)

On 02/15/2011 01:56 AM, Jonathan M Davis wrote:
> On Monday, February 14, 2011 16:30:09 Andrej Mitrovic wrote:
>> Here's something I've noticed (x86 code):
>>
>> void main()
>> {
>>      ulong size = 2;
>>      int[] arr = new int[](size);
>> }
>>
>> This will error with:
>> sizetTest.d(8): Error: cannot implicitly convert expression (size) of
>> type ulong to uint
>>
>> size_t is aliased to uint since I'm running 32bit.
>>
>> I'm really not experienced at all with 64bit, so I don't know if it's
>> good to use uint explicitly (my hunch is that it's not good). uint as
>> the array size wouldn't even compile in 64bit, right?
>>
>> If I'm correct, wouldn't it be better if the error showed that it
>> expects size_t which might be aliased to whatever type for a
>> particular machine?
>
> Use size_t. It's the type which is used. It's aliased to whichever type is
> appropriate for the architecture. On 32 bits, that would be a 32 bit integer, so
> it's uint. On 64 bits, that would be a 64 bit integer, so it's ulong.

Rename size-t, or rather introduce a meaningful standard alias? (would vote for Natural)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On Monday, February 14, 2011 17:06:43 spir wrote:
> On 02/15/2011 01:56 AM, Jonathan M Davis wrote:
> > On Monday, February 14, 2011 16:30:09 Andrej Mitrovic wrote:
> >> Here's something I've noticed (x86 code):
> >> 
> >> void main()
> >> {
> >> 
> >>      ulong size = 2;
> >>      int[] arr = new int[](size);
> >> 
> >> }
> >> 
> >> This will error with:
> >> sizetTest.d(8): Error: cannot implicitly convert expression (size) of
> >> type ulong to uint
> >> 
> >> size_t is aliased to uint since I'm running 32bit.
> >> 
> >> I'm really not experienced at all with 64bit, so I don't know if it's good to use uint explicitly (my hunch is that it's not good). uint as the array size wouldn't even compile in 64bit, right?
> >> 
> >> If I'm correct, wouldn't it be better if the error showed that it expects size_t which might be aliased to whatever type for a particular machine?
> > 
> > Use size_t. It's the type which is used. It's aliased to whichever type is appropriate for the architecture. On 32 bits, that would be a 32 bit integer, so it's uint. On 64 bits, that would be a 64 bit integer, so it's ulong.
> 
> Rename size-t, or rather introduce a meaningful standard alias? (would vote
> for Natural)

Why? size_t is what's used in C++. It's well known and what lots of programmers would expect What would you gain by renaming it?

- Jonathan M Davis

"spir" <denis.spir@gmail.com> wrote in message news:mailman.1648.1297732015.4748.digitalmars-d@puremagic.com...
> On 02/15/2011 01:56 AM, Jonathan M Davis wrote:
>> On Monday, February 14, 2011 16:30:09 Andrej Mitrovic wrote:
>>> Here's something I've noticed (x86 code):
>>>
>>> void main()
>>> {
>>>      ulong size = 2;
>>>      int[] arr = new int[](size);
>>> }
>>>
>>> This will error with:
>>> sizetTest.d(8): Error: cannot implicitly convert expression (size) of
>>> type ulong to uint
>>>
>>> size_t is aliased to uint since I'm running 32bit.
>>>
>>> I'm really not experienced at all with 64bit, so I don't know if it's good to use uint explicitly (my hunch is that it's not good). uint as the array size wouldn't even compile in 64bit, right?
>>>
>>> If I'm correct, wouldn't it be better if the error showed that it expects size_t which might be aliased to whatever type for a particular machine?
>>
>> Use size_t. It's the type which is used. It's aliased to whichever type
>> is
>> appropriate for the architecture. On 32 bits, that would be a 32 bit
>> integer, so
>> it's uint. On 64 bits, that would be a 64 bit integer, so it's ulong.
>
> Rename size-t, or rather introduce a meaningful standard alias? (would vote for Natural)
>

My bikeshed is painted "native" and "word" :)