View mode: basic / threaded / horizontal-split · Log in · Help
February 17, 2011
Re: Integer conversions too pedantic in 64-bit
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.

int ilength(void[] a) @property
{
 return cast(int)a.length;
}

---
int mylen=bb.ilength;
---
February 17, 2011
Re: Integer conversions too pedantic in 64-bit
Funny, as simple as it is, this is a great idea for std.array because it 
shortens the verbose cast(int) a.length to one extra character.  You 
could even put an assert in it to check in debug mode only that the 
conversion is safe.

On 2/17/2011 7:18 AM, Kagamin wrote:
> 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.
>
> int ilength(void[] a) @property
> {
>    return cast(int)a.length;
> }
>
> ---
> int mylen=bb.ilength;
> ---
February 17, 2011
Re: Integer conversions too pedantic in 64-bit
dsimcha Wrote:

> Funny, as simple as it is, this is a great idea for std.array because it 
> shortens the verbose cast(int) a.length to one extra character.  You 
> could even put an assert in it to check in debug mode only that the 
> conversion is safe.

> > int ilength(void[] a) @property
> > {
> >    return cast(int)a.length;
> > }

I'm not sure the code is correct. I have a vague impression that void[] is like byte[], at least, it's used as such, and conversion from int[] to byte[] multiplies the length by 4.
February 17, 2011
Re: Integer conversions too pedantic in 64-bit
On Thu, 17 Feb 2011 09:45:14 -0500, Kagamin <spam@here.lot> wrote:

> dsimcha Wrote:
>
>> Funny, as simple as it is, this is a great idea for std.array because it
>> shortens the verbose cast(int) a.length to one extra character.  You
>> could even put an assert in it to check in debug mode only that the
>> conversion is safe.
>
>> > int ilength(void[] a) @property
>> > {
>> >    return cast(int)a.length;
>> > }
>
> I'm not sure the code is correct. I have a vague impression that void[]  
> is like byte[], at least, it's used as such, and conversion from int[]  
> to byte[] multiplies the length by 4.

Yes, David has proposed a corrected version on the Phobos mailing list:

http://lists.puremagic.com/pipermail/phobos/2011-February/004493.html

-Steve
February 17, 2011
Re: Integer conversions too pedantic in 64-bit
Steven Schveighoffer:

> Yes, David has proposed a corrected version on the Phobos mailing list:
> 
> http://lists.puremagic.com/pipermail/phobos/2011-February/004493.html

I suggest it to return a signed value, like an int. But a signed long is OK too.
I suggest a name as "len" (or "slen") because I often write "length" wrongly.

Does it support code like:
auto l = arr.len;
arr.len = 10;
arr.len++;

A big problem: it's limited to arrays, so aa.len or rbtree.len, set.len, etc, don't work. So I'd like something more standard... So I am not sure this is a good idea.

Bye,
bearophile
February 17, 2011
Re: Integer conversions too pedantic in 64-bit
On Thu, 17 Feb 2011 13:08:08 -0500, bearophile <bearophileHUGS@lycos.com>  
wrote:

> Steven Schveighoffer:
>
>> Yes, David has proposed a corrected version on the Phobos mailing list:
>>
>> http://lists.puremagic.com/pipermail/phobos/2011-February/004493.html
>
> I suggest it to return a signed value, like an int. But a signed long is  
> OK too.
> I suggest a name as "len" (or "slen") because I often write "length"  
> wrongly.

This isn't replacing length, it is in addition to length (which will  
continue to return size_t).

>
> Does it support code like:
> auto l = arr.len;
> arr.len = 10;
> arr.len++;

arr.length = 10 already works.  It's int l = arr.length that doesn't.
if arr.length++ doesn't work already, it should be made to work (separate  
bug).

> A big problem: it's limited to arrays, so aa.len or rbtree.len, set.len,  
> etc, don't work. So I'd like something more standard... So I am not sure  
> this is a good idea.

The point is to avoid code like cast(int)arr.length everywhere you can  
safely assume arr.length can fit in a (u)int.

This case is extremely common for arrays, you seldom have an array of more  
than 2 or 4 billion elements.

For other types, the case might not be as common, plus you can add  
properties to other types, something you cannot do to arrays.

As far as I'm concerned, this isn't going to affect me at all, I like to  
use size_t.  But I don't see the harm in adding it.

-Steve
Top | Discussion index | About this forum | D home