miscellaneous array questions...
simen.kjaras at gmail.com
Tue Jul 21 19:20:28 UTC 2020
On Tuesday, 21 July 2020 at 13:42:15 UTC, Steven Schveighoffer
> On 7/21/20 8:34 AM, Adam D. Ruppe wrote:
>> The others aren't wrong about stack size limits playing some
>> role, but the primary reason is that it is a weird hack for
>> @safe, believe it or not.
>> I don't recall exactly when this was discussed but it came up
>> in the earlier days of @safe, I'm pretty sure it worked before
> I think this was discussed, but was not the reason for the
> limitation. The limitation exists even in D1, which is before
> @safe: https://digitalmars.com/d/1.0/arrays.html#static-arrays
> I have stressed before that any access of a pointer to a large
> object in @safe code should also check that the base of the
> object is not within the null page (this is not currently
> done). This is the only way to ensure safety.
It seems the limitation was introduced in DMD 0.123, in May 2005:
Walter gives some justification in the post immediately following:
> 1) Gigantic static arrays are often either the result of a typo
> or are a
> newbie mistake.
> 2) Such require a lot of memory for the compiler to handle.
> Before the OS
> officially runs out of memory, it goes to greater and greater
> lengths to
> scavenge memory for the compiler, often bringing the computer
> to its knees
> in desperation.
> 3) D needs to be a portable language, and by capping the array
> size a
> program is more likely to be portable.
> 4) Giant arrays are reflected in a corresponding giant size for
> the exe
> 5) There simply isn't a need I can think of for such arrays.
> There shouldn't
> be a problem with allocating them dynamically.
I admit I thought it was an old optlink limitation, but it seems
it's basically arbitrary.
More information about the Digitalmars-d-learn