www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Integer conversions too pedantic in 64-bit

reply Kagamin <spam here.lot> writes:
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;
---
Feb 17 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
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;
 ---
Feb 17 2011
next sibling parent reply Kagamin <spam here.lot> writes:
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.
Feb 17 2011
parent bearophile <bearophileHUGS lycos.com> writes:
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
Feb 17 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Feb 17 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Feb 17 2011