16MB static arrays again...

Tomer Filiba via Digitalmars-d digitalmars-d at puremagic.com
Wed Aug 24 00:50:25 PDT 2016


#WEKA #INDUSTRY

I found this post from 2007 
http://forum.dlang.org/post/fdspch$d3v$1@digitalmars.com that 
refers to this post from 2006 
http://www.digitalmars.com/d/archives/digitalmars/D/37038.html#N37071 -- and I still don't realize, why do static arrays have this size limit on them?

Any linker issues should be contained to the linker (i.e., use a 
different linker, fix your linker). As for cross-device -- if C 
lets me use huge static arrays, why should D impose a limit? As 
for executable failing to load -- we have ~1GB .bss section and a 
~100MB .rodata section. No issues there.

As for the "use dynamic arrays instead", this poses two problems:
1) Why? I know everything in compile-time, why force me to (A) 
allocate it separately in `shared static this()` and (B) 
introduce all sorts of runtime bound checks?

2) Many times I need memory-contiguity, e.g., several big arrays 
inside a struct, which is dumped to disk/sent over network. I 
can't use pointers there.

And on top of it all, this limit *literally* makes no sense:

__gshared ubyte[16*1024*1024] x; // fails to compile

struct S {
     ubyte[10*1024*1024] a;
     ubyte[10*1024*1024] b;
}
__gshared S x;    // compiles

I'm already working on a super-ugly-burn-with-fire mixin that 
generates *structs* in a given size to overcome this limit.


-tomer


More information about the Digitalmars-d mailing list