www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Static arrays size limit, int

reply bearophile <bearophileHUGS lycos.com> writes:
I'd like a higher max size limit for static arrays:
uint[10_000_000] arr;
For the LDC compiler is a fully arbitrary limit, it can support higher values.
I'd like ldc to be free to use a higher limit.


Most/all PC CPUs & operating systems are probably going to become 64 bit, but
in D int values are 32 bit, so some years from now, when everything is 64 bit D
programs will probably keep containing:
int i;
Unless D programmers will train themselves to nearly never use int and usually
use:
long i;
that will be about as equally fast, but less probable to cause integral
overflow.
The choice of 32 bit as default int number in D may look bad few years from now.
I don't see good solution. To me the best solution seems to use "long"
everywhere in future programs fit for a 64 bit world (cent/ucent will be
present, LLVM supports them already, so it's easy to add them to LDC).

Bye,
bearophile
Nov 19 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:he3hk8$6kg$1 digitalmars.com...

 I'd like a higher max size limit for static arrays:
 uint[10_000_000] arr;
 For the LDC compiler is a fully arbitrary limit, it can support higher 
 values. I'd like ldc to be free to use a higher limit.


 Most/all PC CPUs & operating systems are probably going to become 64 bit, 
 but in D int values are 32 bit, so some years from now, when everything is 
 64 bit D programs will probably keep containing:
 int i;
 Unless D programmers will train themselves to nearly never use int and 
 usually use:
 long i;
 that will be about as equally fast, but less probable to cause integral 
 overflow.
 The choice of 32 bit as default int number in D may look bad few years 
 from now.
 I don't see good solution. To me the best solution seems to use "long" 
 everywhere in future programs fit for a 64 bit world (cent/ucent will be 
 present, LLVM supports them already, so it's easy to add them to LDC).

 Bye,
 bearophile


Isn't that more or less what "size_t" is for?
Nov 19 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

 Isn't that more or less what "size_t" is for? 


Do you use size_t and ptrdiff_t often in your D programs?

Bye,
bearophile
Nov 19 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 19 Nov 2009 17:55:35 +0300, bearophile <bearophileHUGS lycos.com>  
wrote:


 Nick Sabalausky:

 Isn't that more or less what "size_t" is for?


 Do you use size_t and ptrdiff_t often in your D programs?

 Bye,
 bearophile


I do, very often (especially size_t). What's wrong with it?
Nov 19 2009
parent "Nick Sabalausky" <a a.a> writes:
"Denis Koroskin" <2korden gmail.com> wrote in message 
news:op.u3nd5txbo7cclz dkoroskin.saber3d.local...

 On Thu, 19 Nov 2009 17:55:35 +0300, bearophile <bearophileHUGS lycos.com> 
 wrote:


 Nick Sabalausky:

 Isn't that more or less what "size_t" is for?


 Do you use size_t and ptrdiff_t often in your D programs?

 Bye,
 bearophile


 I do, very often (especially size_t). What's wrong with it?


It could use a better name (/nitpicking)
Nov 19 2009
prev sibling next sibling parent Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Thu, Nov 19, 2009 at 2:36 PM, bearophile <bearophileHUGS lycos.com> wrote:

 I'd like a higher max size limit for static arrays:
 uint[10_000_000] arr;
 For the LDC compiler is a fully arbitrary limit, it can support higher values.
I'd like ldc to be free to use a higher limit.


 Most/all PC CPUs & operating systems are probably going to become 64 bit, but
in D int values are 32 bit, so some years from now, when everything is 64 bit D
programs will probably keep containing:
 int i;
 Unless D programmers will train themselves to nearly never use int and usually
use:
 long i;
 that will be about as equally fast, but less probable to cause integral
overflow.
 The choice of 32 bit as default int number in D may look bad few years from
now.
 I don't see good solution. To me the best solution seems to use "long"
everywhere in future programs fit for a 64 bit world (cent/ucent will be
present, LLVM supports them already, so it's easy to add them to LDC).

 Bye,
 bearophile


It's not really *easy* to add them to LDC, since they're not
implemented in the frontend at all.
Nov 19 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 I'd like a higher max size limit for static arrays:
 uint[10_000_000] arr;


Why?
Nov 19 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Don:

 Why?


There are C programs that use larghish static 2D arrays that can't be converted
to D1 for LDC as is, because of an arbitrary imposed limit. I'd like the D
specs to state that such limit is implementation-specific, can be different
between different compilers (but if you want you can add to the specs a common
minimum limit).

Bye,
bearophile
Nov 19 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 Most/all PC CPUs & operating systems are probably going to become 64


bit, but in D int values are 32 bit, so some years from now, when
everything is 64 bit D programs will probably keep containing:

 int i; Unless D programmers will train themselves to nearly never use
 int and


usually use:

 long i;



Just use size_t.
Nov 19 2009