When are associative arrays meant to throw a RangeError?

Daniel Murphy yebblies at nospamgmail.com
Sat Feb 18 19:31:11 PST 2012


"Ben Davis" <entheh at cantab.net> wrote in message 
news:jhotcm$13ag$1 at digitalmars.com...
> I've seen some line-blurring between 'null' and 'empty' for dynamic arrays 
> (non-associative). Specifically, I read that array.init returns null for 
> both static and dynamic, but I think I also read that a dynamic array's 
> default value is the empty array. I also observed that null~[1] == [1], 
> and I wondered if actually 'null' becomes an empty array when cast to 
> dynamic array and they're effectively the same thing.
>

null is not the same thing as an empty array, and I'm not aware of any 
situations where null will implicitly turn into one.
null == { length == 0, ptr == null }
empty == { length == 0, ptr != null }
To make an empty array you (generally) need to allocate memory for it, and 
having this happen implicitly would be a problem.

> If I'm right, then the same could be true for assoc arrays - that 'null' 
> cast to an assoc array type becomes an empty assoc array. Which would 
> explain the magic you're seeing.

This is not what's happening.

With the lvalue AA lookup, the call turns into this:
*_d_aaGet(&AA, keyinformation ...) = value;

Because it passes a pointer to the actual AA variable, if the AA doesn't 
exist it is created.  All of the rvalue AA methods behave the same for null 
and empty AAs.

Except for this magic initialization, AAs behave the same as classes - ie a 
reference type. 




More information about the Digitalmars-d mailing list