www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - AA once again

reply bobef <bobef_member pathlink.com> writes:
I want to ask Walter. Few days ago I started a thread about strange (by my
opinion) behavior of AA's [] operator (thread was called AA question). From the
conversation I thought it's not only my opinion. I doub't Water didn't read that
post, but he did not comment. So Walter, please tell me. Why is that AA design?
And what is the most important to me - will you change your mind about it and
"fix" it in near (or not so near) dmd updates or it is staying this way. I'm
asking because I found some bugs in my code based on this behavior I didn't knew
about. And now I have to change all my code that uses AA[] operator. And it is
lot of code! So I prefer to wait few weeks and do something else in this time
rather replacing my [] code with "in"'s and then make it with [] again if
current behavior changes...
Apr 13 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
bobef wrote:


 I want to ask Walter. Few days ago I started a thread about strange (by my
 opinion) behavior of AA's [] operator (thread was called AA question). From the
 conversation I thought it's not only my opinion. I doub't Water didn't read
that
 post, but he did not comment. So Walter, please tell me. Why is that AA design?


I am not Walter, but I don't think the AA behaviour is going to change.
It's using the same (weirdo) definition that C++ STL's "std::map" has:

Reading a key that does not exist, inserts an empty value into the hash!

If you don't agree with that behaviour (I'm not sure why anyone would),
you need to use the "in" operator instead - to check if it exists...


Be aware that there's also a related bug, in that it fails to .init:

// "works":
version(INT) alias int TYPE;
version(VOID) alias void* TYPE;

// fails:
version(FLOAT) alias float TYPE;
version(CHAR) alias char TYPE;

int main()
{
   TYPE[int] hash;

   hash[0]; // inserts a key!
   assert(0 in hash); // argh

   assert(hash[0] == TYPE.init);
   return 0;
}

This is in turn related to the default values of the float/char types.
(as they have non-zero .init, but AAs set all automagic values to zero)

But even if the init values of float and char are returned to a more
sane 0.0 and \0, the AAs still inserts new keys when you read them...


I think it sucks too, but it's just how the D hashes work I'm afraid.
--anders


PS. It's mentioned on the list of common questions from C/C++ users:
     http://www.prowiki.org/wiki4d/wiki.cgi?ShortFrequentAnswers
Apr 13 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
I wrote:


 It's using the same (weirdo) definition that C++ STL's "std::map" has:
 
 Reading a key that does not exist, inserts an empty value into the hash!
 
 If you don't agree with that behaviour (I'm not sure why anyone would),


Sorry, I forgot the case when you use the hash lookup as an lvalue:

http://www.digitalmars.com/d/arrays.html

             if (inword)
	    {   char[] word = input[wstart .. input.length];
		dictionary[word]++;
	    }

Without it, you would be forced to write:
dictionary[word] = dictionary[word] + 1;

Then again, there's already such a limit
on how you can use the .length property ?

--anders
Apr 13 2005
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d3ja39$1ovt$1 digitaldaemon.com...

 I am not Walter, but I don't think the AA behaviour is going to change.


 It's using the same (weirdo) definition that C++ STL's "std::map" has:


I suppose it's for non-class AAs.  Think about it - what would attempting to 
access a nonexistent key do in an int[char[]] array?  Return 0?  Throw an 
exception?  I suppose it's just for consistency between types.  Though I 
agree, it is far less intuitive for class AAs to have to use "in".
Apr 13 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Jarrett Billingsley wrote:


 I suppose it's for non-class AAs.  Think about it - what would attempting to 
 access a nonexistent key do in an int[char[]] array?  Return 0?


I thought so, but it seems that I was in the minority.


 Throw an exception? 


I think it was Matthew that was suggesting this, earlier ?


 I suppose it's just for consistency between types.  Though I 
 agree, it is far less intuitive for class AAs to have to use "in". 


Whatever the reason, it should be clearly documented - since
it's profoundly confusing to several posters to this newsgroup.

--anders
Apr 13 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d3jseu$29tb$2 digitaldaemon.com...

 Jarrett Billingsley wrote:


 I suppose it's for non-class AAs.  Think about it - what would 
 attempting to access a nonexistent key do in an int[char[]] 
 array?  Return 0?


 I thought so, but it seems that I was in the minority.


 Throw an exception?


 I think it was Matthew that was suggesting this, earlier ?


 I suppose it's just for consistency between types.  Though I 
 agree, it is far less intuitive for class AAs to have to use 
 "in".


 Whatever the reason, it should be clearly documented - since
 it's profoundly confusing to several posters to this newsgroup.


It's not just the confusion. IMO the built-in AAs are a (syntactic) 
joke, and I would always have to, in good conscience, caution 
against their use to any D users, just as I do with auto_ptr<> in 
C++.

Pretty sad, really.
Apr 13 2005
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d3ja39$1ovt$1 digitaldaemon.com...

 bobef wrote:


 I want to ask Walter. Few days ago I started a thread about 
 strange (by my
 opinion) behavior of AA's [] operator (thread was called AA 
 question). From the
 conversation I thought it's not only my opinion. I doub't Water 
 didn't read that
 post, but he did not comment. So Walter, please tell me. Why is 
 that AA design?


 I am not Walter, but I don't think the AA behaviour is going to 
 change.
 It's using the same (weirdo) definition that C++ STL's "std::map" 
 has:

 Reading a key that does not exist, inserts an empty value into the 
 hash!

 If you don't agree with that behaviour (I'm not sure why anyone 
 would),
 you need to use the "in" operator instead - to check if it 
 exists...


 Be aware that there's also a related bug, in that it fails to 
 .init:

 // "works":
 version(INT) alias int TYPE;
 version(VOID) alias void* TYPE;

 // fails:
 version(FLOAT) alias float TYPE;
 version(CHAR) alias char TYPE;

 int main()
 {
   TYPE[int] hash;

   hash[0]; // inserts a key!
   assert(0 in hash); // argh

   assert(hash[0] == TYPE.init);
   return 0;
 }

 This is in turn related to the default values of the float/char 
 types.
 (as they have non-zero .init, but AAs set all automagic values to 
 zero)

 But even if the init values of float and char are returned to a 
 more
 sane 0.0 and \0, the AAs still inserts new keys when you read 
 them...


 I think it sucks too, but it's just how the D hashes work I'm 
 afraid.
 --anders


For the benefit of bobef, who may be being misled by the lack of 
response to his concerns, I think it sucks too. I think there are 
very of us who do not.

But I too doubt it'll change.
Apr 13 2005
parent kris <fu bar.org> writes:
Matthew wrote:

 "Anders F Björklund" <afb algonet.se> wrote in message 
 news:d3ja39$1ovt$1 digitaldaemon.com...
 

bobef wrote:



I want to ask Walter. Few days ago I started a thread about 
strange (by my
opinion) behavior of AA's [] operator (thread was called AA 
question). From the
conversation I thought it's not only my opinion. I doub't Water 
didn't read that
post, but he did not comment. So Walter, please tell me. Why is 
that AA design?


I am not Walter, but I don't think the AA behaviour is going to 
change.
It's using the same (weirdo) definition that C++ STL's "std::map" 
has:

Reading a key that does not exist, inserts an empty value into the 
hash!

If you don't agree with that behaviour (I'm not sure why anyone 
would),
you need to use the "in" operator instead - to check if it 
exists...


Be aware that there's also a related bug, in that it fails to 
.init:

// "works":
version(INT) alias int TYPE;
version(VOID) alias void* TYPE;

// fails:
version(FLOAT) alias float TYPE;
version(CHAR) alias char TYPE;

int main()
{
  TYPE[int] hash;

  hash[0]; // inserts a key!
  assert(0 in hash); // argh

  assert(hash[0] == TYPE.init);
  return 0;
}

This is in turn related to the default values of the float/char 
types.
(as they have non-zero .init, but AAs set all automagic values to 
zero)

But even if the init values of float and char are returned to a 
more
sane 0.0 and \0, the AAs still inserts new keys when you read 
them...


I think it sucks too, but it's just how the D hashes work I'm 
afraid.
--anders


 
 
 For the benefit of bobef, who may be being misled by the lack of 
 response to his concerns, I think it sucks too. I think there are 
 very of us who do not.
 
 But I too doubt it'll change.
 



Yep. I seriously doubt it also. Particularly so since these 'complaints' 
have been going strong for a year. The built-in AA does suck. And not 
just because of the awkward semantics.

To be fair, the one beneficial aspect I can note is the lack of casting 
required, given that it's a generic container. But then, so what.
Apr 13 2005
prev sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"bobef" <bobef_member pathlink.com> wrote in message 
news:d3j2p1$1j32$1 digitaldaemon.com...

I want to ask Walter. Few days ago I started a thread about strange (by my
 opinion) behavior of AA's [] operator (thread was called AA question). 
 From the
 conversation I thought it's not only my opinion. I doub't Water didn't 
 read that
 post, but he did not comment. So Walter, please tell me. Why is that AA 
 design?
 And what is the most important to me - will you change your mind about it 
 and
 "fix" it in near (or not so near) dmd updates or it is staying this way. 
 I'm
 asking because I found some bugs in my code based on this behavior I 
 didn't knew
 about. And now I have to change all my code that uses AA[] operator. And 
 it is
 lot of code! So I prefer to wait few weeks and do something else in this 
 time
 rather replacing my [] code with "in"'s and then make it with [] again if
 current behavior changes...


I emailed him last week or so asking for comments about a thread and he said 
he's been busy fixing dmd-120. I think after he feels more comfortable with 
dmd-121 he'll chime in. Either that or he'll pull his old trick of letting 
his code do the talking. It can get frustrating not knowing if he isn't 
responding because he doesn't agree or if he's just busy but that's how it 
goes.
Apr 13 2005