View mode: basic / threaded / horizontal-split · Log in · Help
February 18, 2012
When are associative arrays meant to throw a RangeError?
I can't easily see what the rules are. Specifically, I'm finding:

Chunk[][char[4]] chunks;
//chunks["DATA"] is an array of Chunk objects, where Chunk is a class.
//I'm using this structure to remember positions of chunks in a file format.

//These both work:
chunks["AAAA"]~=new Chunk();
chunks["BBBB"]=chunks["BBBB"]~new Chunk();

//These all throw RangeErrors
Chunk[] tempVar=chunks["CCCC"]~new Chunk();
if (chunks["DDDD"].length!=1) throw new Exception("");
writefln("%s",chunks["EEEE"]);

//This works and formats the null as "[]"
writefln("%s",cast(Chunk[])null);

So, as far as I can tell, chunks[nonexistentKey] throws a RangeError in 
most cases, including with ~ in general, but not if the ~ is used for an 
in-place modification.

My initial expectation would be that every example above would throw a 
RangeError (except the one that doesn't use 'chunks' at all).

So here are my theories, in the approx order I came up with them:

1=. It's an optimisation accident, and it's meant to throw.

1=. It's a nasty bodge specifically to make assoc arrays usable with 
modify-assign expressions.

3. It could be a quirk of assignment expression evaluation order. 
Perhaps the assignment expression FIRST creates an entry in the assoc 
array using the value type's default value (an empty dynamic array), AND 
THEN evaluates the RHS, which is able to read the empty array that's 
just been inserted.

Whatever the case, I couldn't find any documentation on the subject. I 
looked under associative arrays (obviously), and also under assignment 
expressions, and also under expression statements just for good measure.

Would appreciate any comments :)

Thanks,

Ben :)
February 18, 2012
Re: When are associative arrays meant to throw a RangeError?
It's 3.  It also has the nasty side effect that throwing while evaluating 
the rhs leaves the AA with a default-initialized key.

When AA[key] needs to be an lvalue, it gets translated to something like:
*_aa_get_lvalue(AA, key)
which creates the key if it doesn't exist and returns a reference to it.

"Ben Davis" <entheh@cantab.net> wrote in message 
news:jhn2e7$2urh$1@digitalmars.com...
>I can't easily see what the rules are. Specifically, I'm finding:
>
> Chunk[][char[4]] chunks;
> //chunks["DATA"] is an array of Chunk objects, where Chunk is a class.
> //I'm using this structure to remember positions of chunks in a file 
> format.
>
> //These both work:
> chunks["AAAA"]~=new Chunk();
> chunks["BBBB"]=chunks["BBBB"]~new Chunk();
>
> //These all throw RangeErrors
> Chunk[] tempVar=chunks["CCCC"]~new Chunk();
> if (chunks["DDDD"].length!=1) throw new Exception("");
> writefln("%s",chunks["EEEE"]);
>
> //This works and formats the null as "[]"
> writefln("%s",cast(Chunk[])null);
>
> So, as far as I can tell, chunks[nonexistentKey] throws a RangeError in 
> most cases, including with ~ in general, but not if the ~ is used for an 
> in-place modification.
>
> My initial expectation would be that every example above would throw a 
> RangeError (except the one that doesn't use 'chunks' at all).
>
> So here are my theories, in the approx order I came up with them:
>
> 1=. It's an optimisation accident, and it's meant to throw.
>
> 1=. It's a nasty bodge specifically to make assoc arrays usable with 
> modify-assign expressions.
>
> 3. It could be a quirk of assignment expression evaluation order. Perhaps 
> the assignment expression FIRST creates an entry in the assoc array using 
> the value type's default value (an empty dynamic array), AND THEN 
> evaluates the RHS, which is able to read the empty array that's just been 
> inserted.
>
> Whatever the case, I couldn't find any documentation on the subject. I 
> looked under associative arrays (obviously), and also under assignment 
> expressions, and also under expression statements just for good measure.
>
> Would appreciate any comments :)
>
> Thanks,
>
> Ben :)
February 18, 2012
Re: When are associative arrays meant to throw a RangeError?
Daniel Murphy:

> It's 3.  It also has the nasty side effect that throwing while evaluating 
> the rhs leaves the AA with a default-initialized key.

Maybe related to this thread.
A lot of time ago I have added this issue to Bugzilla, I have never received a comment on it, so far:
http://d.puremagic.com/issues/show_bug.cgi?id=3825

Bye,
bearophile
February 18, 2012
Re: When are associative arrays meant to throw a RangeError?
Yes, that's the issue I'm talking about.  In this case no comments means no 
disagreements.  Unfortunately it requires changes to the AA api/codegen to 
fix, so it will probably be around until we move AAs completely into 
druntime.

"bearophile" <bearophileHUGS@lycos.com> wrote in message 
news:jhn604$5ur$1@digitalmars.com...
> Daniel Murphy:
>
>> It's 3.  It also has the nasty side effect that throwing while evaluating
>> the rhs leaves the AA with a default-initialized key.
>
> Maybe related to this thread.
> A lot of time ago I have added this issue to Bugzilla, I have never 
> received a comment on it, so far:
> http://d.puremagic.com/issues/show_bug.cgi?id=3825
>
> Bye,
> bearophile
February 18, 2012
Re: When are associative arrays meant to throw a RangeError?
On Saturday, February 18, 2012 14:46:21 Daniel Murphy wrote:
> Yes, that's the issue I'm talking about.  In this case no comments means no
> disagreements.  Unfortunately it requires changes to the AA api/codegen to
> fix, so it will probably be around until we move AAs completely into
> druntime.

Which should probably be sorted out sooner rather than later given all of the 
bugs involved.

- Jonathan M Davis
February 18, 2012
Re: When are associative arrays meant to throw a RangeError?
Yeah, but that requires a design that fixes everything, including literals, 
template arg deduction, magic initialization etc.

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message 
news:mailman.514.1329537168.20196.digitalmars-d@puremagic.com...
> On Saturday, February 18, 2012 14:46:21 Daniel Murphy wrote:
>> Yes, that's the issue I'm talking about.  In this case no comments means 
>> no
>> disagreements.  Unfortunately it requires changes to the AA api/codegen 
>> to
>> fix, so it will probably be around until we move AAs completely into
>> druntime.
>
> Which should probably be sorted out sooner rather than later given all of 
> the
> bugs involved.
>
> - Jonathan M Davis
February 18, 2012
Re: When are associative arrays meant to throw a RangeError?
On Saturday, February 18, 2012 15:13:38 Daniel Murphy wrote:
> Yeah, but that requires a design that fixes everything, including literals,
> template arg deduction, magic initialization etc.

Oh, it may not be easy, and it may take some time, but it should probably be 
one of the higher priorities.

- Jonathan M Davis
February 18, 2012
Re: When are associative arrays meant to throw a RangeError?
On Fri, Feb 17, 2012 at 09:06:20PM -0800, Jonathan M Davis wrote:
> On Saturday, February 18, 2012 15:13:38 Daniel Murphy wrote:
> > Yeah, but that requires a design that fixes everything, including
> > literals, template arg deduction, magic initialization etc.
> 
> Oh, it may not be easy, and it may take some time, but it should
> probably be one of the higher priorities.
[...]

I agree. AA's are one of the big reasons I chose to learn D. I was very
happy to finally have a language that has runtime speed comparable to
C++ and has built-in AA's. Sad to say, I've been rather disappointed by
the amount of AA related bugs in the current implementation.


T

-- 
MS Windows: 64-bit overhaul of 32-bit extensions and a graphical shell
for a 16-bit patch to an 8-bit operating system originally coded for a
4-bit microprocessor, written by a 2-bit company that can't stand 1-bit
of competition.
February 18, 2012
Re: When are associative arrays meant to throw a RangeError?
On 2/18/12 12:39 AM, H. S. Teoh wrote:
> On Fri, Feb 17, 2012 at 09:06:20PM -0800, Jonathan M Davis wrote:
>> On Saturday, February 18, 2012 15:13:38 Daniel Murphy wrote:
>>> Yeah, but that requires a design that fixes everything, including
>>> literals, template arg deduction, magic initialization etc.
>>
>> Oh, it may not be easy, and it may take some time, but it should
>> probably be one of the higher priorities.
> [...]
>
> I agree. AA's are one of the big reasons I chose to learn D. I was very
> happy to finally have a language that has runtime speed comparable to
> C++ and has built-in AA's. Sad to say, I've been rather disappointed by
> the amount of AA related bugs in the current implementation.

That will change.

Andrei
February 18, 2012
Re: When are associative arrays meant to throw a RangeError?
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message 
news:mailman.521.1329547094.20196.digitalmars-d@puremagic.com...
>
> I agree. AA's are one of the big reasons I chose to learn D. I was very
> happy to finally have a language that has runtime speed comparable to
> C++ and has built-in AA's. Sad to say, I've been rather disappointed by
> the amount of AA related bugs in the current implementation.
>

Another way of looking at this is that the issues with AAs are one of the 
bigger implementation problems D has these days - not compiler crashes, 
wrong code generation, thousands of ice bugs with reasonable looking code... 
The implementation has come a long way in the last couple of years.
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home