www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - AA question

reply bobef <bobef_member pathlink.com> writes:
When I try to read (AA is right of the = ) key that does not exists from AA it
gets created. Is this normal?
I mean something like this:

foo[bar] aa;
for bb=aa[bar_that_doesnt_exists_in_the_aa];

And then bb is not null but new foo instead. And is even not new foo because if
it is class and I read from it program crashes...
Apr 08 2005
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
You are correct.  If you want to check if a given key exists, then use 
the expression:
	<key> in <variable>
which returns a pointer.  If the key does NOT exist, then it returns 
null and the key is NOT added to the array. But if the key exists, then 
it returns a pointer to the value.

bobef wrote:

 When I try to read (AA is right of the = ) key that does not exists from AA it
 gets created. Is this normal?
 I mean something like this:
 
 foo[bar] aa;
 for bb=aa[bar_that_doesnt_exists_in_the_aa];
 
 And then bb is not null but new foo instead. And is even not new foo because if
 it is class and I read from it program crashes...
Apr 08 2005
parent reply bobef <bobef_member pathlink.com> writes:
Yes I know that. But I think new value should be added only on assigment...
Am I wrong? And if I do why?

In article <d36jna$3cs$1 digitaldaemon.com>, Russ Lewis says...

You are correct.  If you want to check if a given key exists, then use 
the expression:
	<key> in <variable>
which returns a pointer.  If the key does NOT exist, then it returns 
null and the key is NOT added to the array. But if the key exists, then 
it returns a pointer to the value.

bobef wrote:

 When I try to read (AA is right of the = ) key that does not exists from AA it
 gets created. Is this normal?
 I mean something like this:
 
 foo[bar] aa;
 for bb=aa[bar_that_doesnt_exists_in_the_aa];
 
 And then bb is not null but new foo instead. And is even not new foo because if
 it is class and I read from it program crashes...
Apr 08 2005
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
This has been argued extensively before; some people think that it is a 
good idea; others do not.  Frankly, I'm not too up-to-speed on the exact 
reasoning, but you should be able to search the newsgroup for info.

Anybody have a link, or a message name?

bobef wrote:

 Yes I know that. But I think new value should be added only on assigment...
 Am I wrong? And if I do why?
 
 In article <d36jna$3cs$1 digitaldaemon.com>, Russ Lewis says...
 

You are correct.  If you want to check if a given key exists, then use 
the expression:
	<key> in <variable>
which returns a pointer.  If the key does NOT exist, then it returns 
null and the key is NOT added to the array. But if the key exists, then 
it returns a pointer to the value.

bobef wrote:


When I try to read (AA is right of the = ) key that does not exists from AA it
gets created. Is this normal?
I mean something like this:

foo[bar] aa;
for bb=aa[bar_that_doesnt_exists_in_the_aa];

And then bb is not null but new foo instead. And is even not new foo because if
it is class and I read from it program crashes...
Apr 08 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Russ Lewis wrote:

 This has been argued extensively before; some people think that it is a 
 good idea; others do not.  Frankly, I'm not too up-to-speed on the exact 
 reasoning, but you should be able to search the newsgroup for info.
 
 Anybody have a link, or a message name?


Let's just say, I'd like to hear the motivations for the current 
behavior (again)!


 bobef wrote:
 

 Yes I know that. But I think new value should be added only on 
 assigment...
 Am I wrong? And if I do why?

 In article <d36jna$3cs$1 digitaldaemon.com>, Russ Lewis says...


 You are correct.  If you want to check if a given key exists, then 
 use the expression:
     <key> in <variable>
 which returns a pointer.  If the key does NOT exist, then it returns 
 null and the key is NOT added to the array. But if the key exists, 
 then it returns a pointer to the value.

 bobef wrote:


 When I try to read (AA is right of the = ) key that does not exists 
 from AA it
 gets created. Is this normal?
 I mean something like this:

 foo[bar] aa;
 for bb=aa[bar_that_doesnt_exists_in_the_aa];

 And then bb is not null but new foo instead. And is even not new foo 
 because if
 it is class and I read from it program crashes...
Apr 08 2005
parent reply "Charlie" <charles jwavro.com> writes:
 Let's just say, I'd like to hear the motivations for the current
 behavior (again)!


I'd like to hear these too , is any one actually _for_ this ?

Charlie


"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:4257003D.3030706 nospam.org...

 Russ Lewis wrote:

 This has been argued extensively before; some people think that it is a
 good idea; others do not.  Frankly, I'm not too up-to-speed on the exact
 reasoning, but you should be able to search the newsgroup for info.

 Anybody have a link, or a message name?


 Let's just say, I'd like to hear the motivations for the current
 behavior (again)!


 bobef wrote:


 Yes I know that. But I think new value should be added only on
 assigment...
 Am I wrong? And if I do why?

 In article <d36jna$3cs$1 digitaldaemon.com>, Russ Lewis says...


 You are correct.  If you want to check if a given key exists, then
 use the expression:
     <key> in <variable>
 which returns a pointer.  If the key does NOT exist, then it returns
 null and the key is NOT added to the array. But if the key exists,
 then it returns a pointer to the value.

 bobef wrote:


 When I try to read (AA is right of the = ) key that does not exists
 from AA it
 gets created. Is this normal?
 I mean something like this:

 foo[bar] aa;
 for bb=aa[bar_that_doesnt_exists_in_the_aa];

 And then bb is not null but new foo instead. And is even not new foo
 because if
 it is class and I read from it program crashes...
Apr 08 2005
parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 Let's just say, I'd like to hear the motivations for the current
 behavior (again)!


 I'd like to hear these too , is any one actually _for_ this ?


Yes. I am. This is like it's done in Qt, and I think it is quite useful.  
There are two operators for AAs:

[]   - insert (+retrieve) value
in   - test (+retrieve) value

As you can see, there already is an operator for looking up a value (it  
returns a pointer to the value, i think, or null if it isn't in the AA).  
So you can change it if it is found, without looking it up again. If you  
would change the behaviour of [], there would be no operator for "give me  
the value to key X, or the default if there isn't an X in the map". It is  
very important to have an operator for every of these use-cases, because  
all workarounds are much slower and would thus render the AA useless for  
programmers needing the speed.

Ciao
uwe
Apr 08 2005
next sibling parent reply Ben Hinkle <Ben_member pathlink.com> writes:
In article <opsoxq1ipy6yjbe6 sandmann.maerchenwald.net>, Uwe Salomon says...

 Let's just say, I'd like to hear the motivations for the current
 behavior (again)!


 I'd like to hear these too , is any one actually _for_ this ?


Yes. I am. This is like it's done in Qt, and I think it is quite useful.  
There are two operators for AAs:

[]   - insert (+retrieve) value
in   - test (+retrieve) value

As you can see, there already is an operator for looking up a value (it  
returns a pointer to the value, i think, or null if it isn't in the AA).  
So you can change it if it is found, without looking it up again. If you  
would change the behaviour of [], there would be no operator for "give me  
the value to key X, or the default if there isn't an X in the map". It is  
very important to have an operator for every of these use-cases, because  
all workarounds are much slower and would thus render the AA useless for  
programmers needing the speed.


I think most people here would agree. The question is if [] and "in" are those
operators. I had always assumed C++ inserts on [] because it returns a reference
for either lvalue or rvalue contexts. In D the compiler detects the most common
rvalue context (opIndexAssign) and we can have [] insert in that case and not
insert otherwise. 
I had made a few posts about why inserting on lookup can be bad: it prevents
properties from returning an AA (properties can return dynamic arrays just fine)
and it makes concurrent AAs use a different API since changing the container on
lookup is a big no-no for multi-threaded apps.
Apr 09 2005
next sibling parent Ben Hinkle <Ben_member pathlink.com> writes:
In D the compiler detects the most common
rvalue context (opIndexAssign) 


oops- I meant lvalue. :-P
To make this post more interesting, though, let me toss in a URL:
http://www.planetfall.pwp.blueyonder.co.uk/notcpp.html
the section about lvalues and operator overloading.
Apr 09 2005
prev sibling parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 I think most people here would agree. The question is if [] and "in" are  
 those operators.


One could discuss about it, yes. But i want to see DMD 1.0, thus i try not  
to request any new features or changes in the language. This solutions  
works, and it's not a bad solution. By the way, is there an opLookup() or  
something else to overload the "in" operator?


 In D the compiler detects the most common
 rvalue context (opIndexAssign) and we can have [] insert in that case  
 and not insert otherwise.


You mean if you write your own associative container, you would write  
opIndex() to *not* insert the lookup-value? Hm, i think it's better to  
provide a member function doing that (if there is no opLookup), to make  
the use consistent.


 it prevents
 properties from returning an AA (properties can return dynamic arrays  
 just fine)


I don't understand that. You mean a function like that is not possible:

struct SomeStruct
{
   int[char[]] property()
   {
     return something;
   }
}

void func()
{
   SomeStruct struc;
   printf("%i\n", struc.property["name"]);
}


 and it makes concurrent AAs use a different API since changing the  
 container on lookup is a big no-no for multi-threaded apps.


Well, i would rather change the api to reflect that. Don't provide  
opIndex[] for concurrent AAs.

By the way, i like the implementation of your MinTL very much. I have  
written a "vector" container which provides full Qt, STL and D API (except  
the buggy opCmp/opEqual, they are commented out), and handles the memory  
management for himself. If someone is interested:

http://www.uwesalomon.de/code/vector.d (doc is doxygen, but i didn't  
generate it. General explanation beginning in line 248. But it's like Qt.)
http://www.uwesalomon.de/code/global.d (needed as well.)

I will write some other containers as i need them, at least a linked list  
and a map (perhaps a red/tree-map as well to learn the algorithm). Is  
there a need for the full set of Qt containers (Vector, List, LinkedList,  
Map, HashMap; perhaps VarLengthArray)? That would make me implement them  
all...

Ciao
uwe
Apr 09 2005
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Uwe Salomon schrieb am Sat, 09 Apr 2005 18:26:12 +0200:

 By the way, i like the implementation of your MinTL very much. I have  
 written a "vector" container which provides full Qt, STL and D API (except  
 the buggy opCmp/opEqual, they are commented out), and handles the memory  
 management for himself. If someone is interested:

 http://www.uwesalomon.de/code/vector.d (doc is doxygen, but i didn't  
 generate it. General explanation beginning in line 248. But it's like Qt.)
 http://www.uwesalomon.de/code/global.d (needed as well.)


"Implementirung. Operazionen. Konstrukzion/destrukzion."

I've never seen Ultradeutsh before :P

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCWA2I3w+/yD4P9tIRAoDtAJ4mMVXLKaC6Tbf7Fb9+3tHKoMk7RwCghgP0
lIJozj8tX0OgboOYqbd6j+o=
=h0Uz
-----END PGP SIGNATURE-----
Apr 09 2005
parent "Uwe Salomon" <post uwesalomon.de> writes:
 "Implementirung. Operazionen. Konstrukzion/destrukzion."

 I've never seen Ultradeutsh before :P


Ah. You know Ultradeutsh? Actually, i use wunschdeutsch in the code  
comments... But perhaps this is a bit OT here ;o)

Ciao
uwe
Apr 09 2005
prev sibling parent reply Ben Hinkle <Ben_member pathlink.com> writes:
In article <opsoy3xye46yjbe6 sandmann.maerchenwald.net>, Uwe Salomon says...

 I think most people here would agree. The question is if [] and "in" are  
 those operators.


One could discuss about it, yes. But i want to see DMD 1.0, thus i try not  
to request any new features or changes in the language. This solutions  
works, and it's not a bad solution. 


It's not a total disaster, true, but if there is a better solution we should
find it before 1.0 otherwise the bar goes way up for changing behavior IMO.


By the way, is there an opLookup() or  
something else to overload the "in" operator?


no. In my code I've been using opIn as a placeholder.


 In D the compiler detects the most common
 rvalue context (opIndexAssign) and we can have [] insert in that case  
 and not insert otherwise.


You mean if you write your own associative container, you would write  
opIndex() to *not* insert the lookup-value? Hm, i think it's better to  
provide a member function doing that (if there is no opLookup), to make  
the use consistent.


I'm saying we don't have to follow the C++ model due to language behaviors. The
D language can allow us to change [] in an rvalue context to not insert. In C++
it must insert - there's basically no choice.


 it prevents
 properties from returning an AA (properties can return dynamic arrays  
 just fine)


I don't understand that. You mean a function like that is not possible:

struct SomeStruct
{
   int[char[]] property()
   {
     return something;
   }
}

void func()
{
   SomeStruct struc;
   printf("%i\n", struc.property["name"]);
}


correct. If property returned a dynamic array the code struc.property["name"]
would be ok. With AAs it is not.


 and it makes concurrent AAs use a different API since changing the  
 container on lookup is a big no-no for multi-threaded apps.


Well, i would rather change the api to reflect that. Don't provide  
opIndex[] for concurrent AAs.


eek. That's a very convenient syntax that I think users would be sad to see
unsupported.


By the way, i like the implementation of your MinTL very much. I have  
written a "vector" container which provides full Qt, STL and D API (except  
the buggy opCmp/opEqual, they are commented out), and handles the memory  
management for himself. If someone is interested:

http://www.uwesalomon.de/code/vector.d (doc is doxygen, but i didn't  
generate it. General explanation beginning in line 248. But it's like Qt.)
http://www.uwesalomon.de/code/global.d (needed as well.)

I will write some other containers as i need them, at least a linked list  
and a map (perhaps a red/tree-map as well to learn the algorithm). Is  
there a need for the full set of Qt containers (Vector, List, LinkedList,  
Map, HashMap; perhaps VarLengthArray)? That would make me implement them  
all...


Cool! I hadn't seen this code before. Maybe I just missed it but I would post an
announcement to the D.announce and/or the D.dtl groups.
Apr 09 2005
parent "Uwe Salomon" <post uwesalomon.de> writes:
 http://www.uwesalomon.de/code/vector.d (doc is doxygen, but i didn't
 generate it. General explanation beginning in line 248. But it's like  
 Qt.)
 http://www.uwesalomon.de/code/global.d (needed as well.)


 Cool! I hadn't seen this code before. Maybe I just missed it but I would  
 post an
 announcement to the D.announce and/or the D.dtl groups.


You couldn't see it before. I uploaded it today and didn't post anything  
anywhere except this message. But after finishing the list i will post in  
D.announce. Anywhere else i should write something? In the Wiki? (You see,  
i'm not very experienced with "open source development" :o).

Ah, if you like you can incorporate the vector in your library (if that's  
possible and feasible). I did some benchmarking with appending a lot of  
elements one after the other, and it is quite a bit faster than  
temporarily increasing the length to avoid reallocations.

Ciao
uwe
Apr 09 2005
prev sibling next sibling parent reply novice2 <novice2_member pathlink.com> writes:
In article <opsoxq1ipy6yjbe6 sandmann.maerchenwald.net>, Uwe Salomon says...


If you  
would change the behaviour of [], there would be no operator for "give me  
the value to key X, or the default if there isn't an X in the map".


No! "Giving default" if X not exists and "inserting if not exists" are very
different. Let's reading aa[not_exist_key] give default, but not write any data
to AA. This is side effect. After this "in" operator useless. Information about
"was element exists in AA" lost.
Apr 10 2005
parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 If you
 would change the behaviour of [], there would be no operator for "give  
 me
 the value to key X, or the default if there isn't an X in the map".


 No! "Giving default" if X not exists and "inserting if not exists" are  
 very
 different. Let's reading aa[not_exist_key] give default, but not write  
 any data
 to AA. This is side effect. After this "in" operator useless.  
 Information about
 "was element exists in AA" lost.


Jep, sorry. I meant "lookup X and insert default if X doesn't exist". Thus  
"in" only does a lookup, and "[]" inserts if necessary.

Ciao
uwe
Apr 10 2005
next sibling parent reply Ben Hinkle <Ben_member pathlink.com> writes:
In article <opso0b4nv26yjbe6 sandmann.maerchenwald.net>, Uwe Salomon says...

 If you
 would change the behaviour of [], there would be no operator for "give  
 me
 the value to key X, or the default if there isn't an X in the map".


 No! "Giving default" if X not exists and "inserting if not exists" are  
 very
 different. Let's reading aa[not_exist_key] give default, but not write  
 any data
 to AA. This is side effect. After this "in" operator useless.  
 Information about
 "was element exists in AA" lost.


Jep, sorry. I meant "lookup X and insert default if X doesn't exist". Thus  
"in" only does a lookup, and "[]" inserts if necessary.


My preferred AA api, as posted a while ago to Matthew's "in stinks" thread:
bit opIn(Key key) // possibly return value* instead
Value opIndex(Key key) // throws on missing key
void opIndexAssign(Value value, Key key) // insert
bit contains(Key key, out Value value)
void remove(Key key) // ignores missing key
Value* insert(Key key) // lookup and insert if not present
.. rest as before except "delete" is removed...

The functions with name opFoo are for the operators in, [] and []=

-Ben

ps - it would be nice to hear boo from Walter what chances any changes to AAs
have of happening. I have the feeling the chances are around 10% or less.
Apr 10 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Ben Hinkle" <Ben_member pathlink.com> wrote in message 
news:d3bg60$2n7q$1 digitaldaemon.com...

 In article <opso0b4nv26yjbe6 sandmann.maerchenwald.net>, Uwe 
 Salomon says...

 If you
 would change the behaviour of [], there would be no operator 
 for "give
 me
 the value to key X, or the default if there isn't an X in the 
 map".


 No! "Giving default" if X not exists and "inserting if not 
 exists" are
 very
 different. Let's reading aa[not_exist_key] give default, but not 
 write
 any data
 to AA. This is side effect. After this "in" operator useless.
 Information about
 "was element exists in AA" lost.


Jep, sorry. I meant "lookup X and insert default if X doesn't 
exist". Thus
"in" only does a lookup, and "[]" inserts if necessary.


 My preferred AA api, as posted a while ago to Matthew's "in 
 stinks" thread:
 bit opIn(Key key) // possibly return value* instead


Agree, apart from Value* part


 Value opIndex(Key key) // throws on missing key


Agree


 void opIndexAssign(Value value, Key key) // insert


Agree


 bit contains(Key key, out Value value)


Agree. (I think it was me that suggested this one, so am bound to 
agree <g>)


 void remove(Key key) // ignores missing key


Don't agree with ignoring missing thing, although not 100% about it


 Value* insert(Key key) // lookup and insert if not present


Don't get this? What get's inserted? Surely it needs a second param, 
as in

<whatever> insert(Key key, Value value):

??

Now, as to <whatever> is, that depends on how you respond to the 
above question. My suspicion is that you've used Value* so that some 
can write to it, which I think sucks, I'm afraid. I really don't 
think D should be flirting with pointers in such cases. Also, what's 
wrong with the (Key, Value) syntax?


 .. rest as before except "delete" is removed...


Agree



 -Ben

 ps - it would be nice to hear boo from Walter what chances any 
 changes to AAs
 have of happening.


Seconded.


 I have the feeling the chances are around 10% or less.


Optimist!
Apr 13 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 My preferred AA api, as posted a while ago to Matthew's "in stinks" 
 thread:
 bit opIn(Key key) // possibly return value* instead


 Agree, apart from Value* part


my preference, too. I haven't thought too hard about use cases for the 
value* form.


 Value opIndex(Key key) // throws on missing key


 Agree


 void opIndexAssign(Value value, Key key) // insert


 Agree


 bit contains(Key key, out Value value)


 Agree. (I think it was me that suggested this one, so am bound to agree 
 <g>)


I should have been more careful in attributing the different ideas since my 
saying "my preferred API" implicitly means I came up with the API, which 
isn't right.


 void remove(Key key) // ignores missing key


 Don't agree with ignoring missing thing, although not 100% about it


I figured removing something that doesn't exist is a no-op. The 
post-condition that the AA doesn't contain the key is true.


 Value* insert(Key key) // lookup and insert if not present


 Don't get this? What get's inserted? Surely it needs a second param, as in

 <whatever> insert(Key key, Value value):

 ??

 Now, as to <whatever> is, that depends on how you respond to the above 
 question. My suspicion is that you've used Value* so that some can write 
 to it, which I think sucks, I'm afraid. I really don't think D should be 
 flirting with pointers in such cases. Also, what's wrong with the (Key, 
 Value) syntax?


I have a feeling Walter likes the current behavior because of the example in 
the Array section with the magic line
  count[word]++;
And so I wanted to supply something similar and the best way I could see was 
"insert":
  (*count.insert(word))++
A better name would help. I thought of calling it insertKey but then I 
shortened it to just insert, perhaps by mistake. Having insert take a key 
and value makes it the effectively the same as opIndexAssign, which seems 
redundant. If you scroll up you'll see I put the comment "// insert" next to 
opIndexAssign so arguably this "insert" name needs to change.
Apr 14 2005
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
 bit contains(Key key, out Value value)


 Agree. (I think it was me that suggested this one, so am bound to agree <g>)


 I should have been more careful in attributing the different ideas since my
saying "my preferred API" implicitly means 
 I came up with the API, which isn't right.


It was no problem. Just yanking ya chain. ;)


 void remove(Key key) // ignores missing key


 Don't agree with ignoring missing thing, although not 100% about it


 I figured removing something that doesn't exist is a no-op. The post-condition
that the AA doesn't contain the key is 
 true.


I'm still feeling a bit unsure, but I always err on the side of strictness. If
people aren't too tired by now, I'd be 
interested in hearing thoughts on the matter.


 Value* insert(Key key) // lookup and insert if not present


 Don't get this? What get's inserted? Surely it needs a second param, as in

 <whatever> insert(Key key, Value value):

 ??

 Now, as to <whatever> is, that depends on how you respond to the above
question. My suspicion is that you've used 
 Value* so that some can write to it, which I think sucks, I'm afraid. I really
don't think D should be flirting with 
 pointers in such cases. Also, what's wrong with the (Key, Value) syntax?


 I have a feeling Walter likes the current behavior because of the example in
the Array section with the magic line
  count[word]++;
 And so I wanted to supply something similar and the best way I could see was
"insert":
  (*count.insert(word))++
 A better name would help. I thought of calling it insertKey but then I
shortened it to just insert, perhaps by 
 mistake. Having insert take a key and value makes it the effectively the same
as opIndexAssign, which seems redundant. 
 If you scroll up you'll see I put the comment "// insert" next to
opIndexAssign so arguably this "insert" name needs 
 to change.


Ok. Maybe we need to have code samples / use cases for all the proposed syntax?
(I'm such a dumb ass, as I really need 
to see code in order to think about it <g>)

I just have a really bad feeling about pointers being anywhere in the syntax
for D for things that do not directly 
pertain to talking to C APIs. Otherwise, why don't we just drop the ambiguities
that come with references, go with 
pointers for objects, and clear up the identity/equality issue? <g>
Apr 14 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 void remove(Key key) // ignores missing key


 Don't agree with ignoring missing thing, although not 100% about it


 I figured removing something that doesn't exist is a no-op. The 
 post-condition that the AA doesn't contain the key is true.


 I'm still feeling a bit unsure, but I always err on the side of 
 strictness. If people aren't too tired by now, I'd be interested in 
 hearing thoughts on the matter.


To elaborate on my first reply, to me removing a key that isn't in the array 
is similar to closing a stream that is already closed. I see both situations 
as no-ops since the requested end-state is already satisfied. The basic 
principle is "no harm no foul". I'd be interesting in more opinions, too, 
though.


 Value* insert(Key key) // lookup and insert if not present


 Don't get this? What get's inserted? Surely it needs a second param, as 
 in

 <whatever> insert(Key key, Value value):




 Ok. Maybe we need to have code samples / use cases for all the proposed 
 syntax? (I'm such a dumb ass, as I really need to see code in order to 
 think about it <g>)


Here's the API with more details/examples. The array is variable "x", the 
key "key" and the value "val".

function:
  bit opIn(Key key)
example:
  if (key in x) {...}
  Returns true iff key is in x.

function:
  Value opIndex(Key key) (note this is internal to the compiler impl and 
isn't user visible)
example:
  val = x[key];
  Lookup and return the value for key. Throws an exeption if key is not in 
x. Result is not an lvalue.

function:
  void opIndexAssign(Value val, Key key) (compiler internal impl)
example:
  x[key] = val;
  Associates val with key. Inserts if key is not in x and otherwise 
overwrites previous value. This is the only syntax where x[key] can be used 
as an lvalue.

function:
  bit contains(Key key, out Value val)
example:
  if (x.contains(key,val)) {...}
  Returns true iff key is in x. If key is in x assigns the associated value 
to val.

function:
  void remove(Key key)
example:
  x.remove(key);
  Removes key from x if key is in x.

function:
  Value* insert(Key key)
examples:
  (*x.insert(key)) += 10;
  foo(*x.insert(key)) // where foo is void foo(out Value val);
  If key is in x returns a pointer to the associated value and otherwise 
insert key with the default value and return a pointer to it. Note that 
x[key] = value is equivalent to *x.insert(key) = value;

I'm tempted to add some more like
  Value replace(Key key, Value value)
  Value* query(Key key) // return null if key not in x
but I'll hold off on those. They would be nice to have IMO. The reason for 
adding more sophisticated functions for AAs than dynamic arrays is that 
writing multiple lookups for AA is significantly more expensive for 
performance than dynamic arrays.


 I just have a really bad feeling about pointers being anywhere in the 
 syntax for D for things that do not directly pertain to talking to C APIs. 
 Otherwise, why don't we just drop the ambiguities that come with 
 references, go with pointers for objects, and clear up the 
 identity/equality issue? <g>


Exposing the pointer would only happen when you can't use the x[key]=value 
syntax. The "advanced maneuver" of inserting, initializing and returning an 
lvalue needs to be possible and that's where the pointers/references come 
in. If D had references or out-references or whatever then I agree it 
probably would be nice to remove the pointer stuff. Or if D had a different 
syntax than x[key] for indicating it should return an lvalue that would 
work, too.
Apr 14 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:d3lulk$11pd$1 digitaldaemon.com...

 void remove(Key key) // ignores missing key


 Don't agree with ignoring missing thing, although not 100% 
 about it


 I figured removing something that doesn't exist is a no-op. The 
 post-condition that the AA doesn't contain the key is true.


 I'm still feeling a bit unsure, but I always err on the side of 
 strictness. If people aren't too tired by now, I'd be interested 
 in hearing thoughts on the matter.


 To elaborate on my first reply, to me removing a key that isn't in 
 the array is similar to closing a stream that is already closed. I 
 see both situations as no-ops since the requested end-state is 
 already satisfied. The basic principle is "no harm no foul". I'd 
 be interesting in more opinions, too, though.


Impishly mixing threads of contention(/contentiousness), I'd say 
that if it's part of the contract of remove(), then there's no 
problem. ;)


 Value* insert(Key key) // lookup and insert if not present


 Don't get this? What get's inserted? Surely it needs a second 
 param, as in

 <whatever> insert(Key key, Value value):




 Ok. Maybe we need to have code samples / use cases for all the 
 proposed syntax? (I'm such a dumb ass, as I really need to see 
 code in order to think about it <g>)


 Here's the API with more details/examples. The array is variable 
 "x", the key "key" and the value "val".

 function:
  bit opIn(Key key)
 example:
  if (key in x) {...}
  Returns true iff key is in x.


Totally agree


 function:
  Value opIndex(Key key) (note this is internal to the compiler 
 impl and isn't user visible)
 example:
  val = x[key];
  Lookup and return the value for key. Throws an exeption if key is 
 not in x. Result is not an lvalue.


Totally agree.


 function:
  void opIndexAssign(Value val, Key key) (compiler internal impl)
 example:
  x[key] = val;
  Associates val with key. Inserts if key is not in x and otherwise 
 overwrites previous value. This is the only syntax where x[key] 
 can be used as an lvalue.


Totally agree


 function:
  bit contains(Key key, out Value val)
 example:
  if (x.contains(key,val)) {...}
  Returns true iff key is in x. If key is in x assigns the 
 associated value to val.


Agree, except I think there should also be an overload that doesn't 
take the out value, i.e. is just a method-form equivalent to "in"


 function:
  void remove(Key key)
 example:
  x.remove(key);
  Removes key from x if key is in x.


Totally agree


 function:
  Value* insert(Key key)
 examples:
  (*x.insert(key)) += 10;
  foo(*x.insert(key)) // where foo is void foo(out Value val);
  If key is in x returns a pointer to the associated value and 
 otherwise insert key with the default value and return a pointer 
 to it. Note that x[key] = value is equivalent to *x.insert(key) = 
 value;


Don't like it, I'm afraid. Been reading up on some more 'advanced' 
Python recently, and the use of * there seems exceedingly foreign 
and hacky. This gives me the very same impression. I respectfully 
submit that both your examples syntactically suck.

I see where you're coming from, though, which I'd not done earlier 
in the thread. What you're looking for is how to support a 
somewhat-analoguous behaviour for other operations as exists for 
[]=. In C++ we'd return a reference from insert() and it'd be 
simple.

Do I rightly recall recent calls for returning lvalues from 
functions? If so, that'd be the right approach. If not, I think your 
*-hack is kind of sticking plaster on a deeper inadequacy in D.

I feel/hope that there's a solution to the wider issue, but 
nothing's coming to mind at the moment.

I suggest this one is marked for further discussion.


 I'm tempted to add some more like
  Value replace(Key key, Value value)
  Value* query(Key key) // return null if key not in x
 but I'll hold off on those. They would be nice to have IMO. The 
 reason for adding more sophisticated functions for AAs than 
 dynamic arrays is that writing multiple lookups for AA is 
 significantly more expensive for performance than dynamic arrays.


 I just have a really bad feeling about pointers being anywhere in 
 the syntax for D for things that do not directly pertain to 
 talking to C APIs. Otherwise, why don't we just drop the 
 ambiguities that come with references, go with pointers for 
 objects, and clear up the identity/equality issue? <g>


 Exposing the pointer would only happen when you can't use the 
 x[key]=value syntax. The "advanced maneuver" of inserting, 
 initializing and returning an lvalue needs to be possible and 
 that's where the pointers/references come in. If D had references 
 or out-references or whatever then I agree it probably would be 
 nice to remove the pointer stuff. Or if D had a different syntax 
 than x[key] for indicating it should return an lvalue that would 
 work, too.


Both interesting. I suspect Walter might have one of his 
inspirations on this one, if we can sufficiently convince him that 
the pointer stuff is un appealing.
Apr 15 2005
prev sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Uwe Salomon wrote:


 If you would change the behaviour of [], there would be no
 operator for "give  me the value to key X, or the default if
 there isn't an X in the map".


 
 No! "Giving default" if X not exists and "inserting if not exists"
  are  very different. Let's reading aa[not_exist_key] give default,
 but not write  any data to AA. This is side effect. After this "in"
 operator useless. Information about "was element exists in AA"
 lost.


 
 Jep, sorry. I meant "lookup X and insert default if X doesn't exist".
  Thus  "in" only does a lookup, and "[]" inserts if necessary.


Do you have any real-life examples of the "give me the value of key X
or create and insert a new zero entry for key X and return it to me" ?

I know that C++/STL "map" does it that way, just wondered how it would
be used in actual code (as I happen to think that it's an ugly bug...)


Inserting for lvalues is OK and kinda neat, but inserting for rvalues ?
(it would most definitely have to be documented in <blink> tags, or so)

And like has been mentioned over and over, it's not even a .init/new -
but just a dummy entry full of zeroes ? (just allocated with calloc...)

--anders
Apr 10 2005
next sibling parent reply Ben Hinkle <Ben_member pathlink.com> writes:
Do you have any real-life examples of the "give me the value of key X
or create and insert a new zero entry for key X and return it to me" ?


The word-count example at the bottom of the Array doc has something like
count[word]++;
which only works because the counts are ints and start at 0. Note also no
user-defined type could support syntax like that without changing the language
somehow (eg by adding references).
Apr 10 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


 The word-count example at the bottom of the Array doc has something like
 count[word]++;
 which only works because the counts are ints and start at 0.


I think it would work the same if rvalue defaulted to zero,
and lvalue inserted the new value ? Assuming that ++ expands
to something similar to: "count[word] = count[word] + 1;" ?

--anders
Apr 10 2005
parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 I think it would work the same if rvalue defaulted to zero,
 and lvalue inserted the new value ? Assuming that ++ expands
 to something similar to: "count[word] = count[word] + 1;" ?


But ++ (and += and friends) is guaranteed to evaluate the operand only  
once...

Ciao
uwe
Apr 10 2005
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Uwe Salomon wrote:


 I think it would work the same if rvalue defaulted to zero,
 and lvalue inserted the new value ? Assuming that ++ expands
 to something similar to: "count[word] = count[word] + 1;" ?


 
 But ++ (and += and friends) is guaranteed to evaluate the operand only  
 once...


Maybe it really is broken by design, then. That's too bad...

--anders
Apr 10 2005
prev sibling parent "Uwe Salomon" <post uwesalomon.de> writes:
 Inserting for lvalues is OK and kinda neat, but inserting for rvalues ?
 (it would most definitely have to be documented in <blink> tags, or so)

 And like has been mentioned over and over, it's not even a .init/new -
 but just a dummy entry full of zeroes ? (just allocated with calloc...)


Hm. You are right. Perhaps this should be changed. Everything i needed  
until now was a function like this:

T lookup(Key key, T defaultValue)

which returns the value for key or defaultValue if key isn't in the map.  
No fancy inserting...

Ciao
uwe
Apr 10 2005
prev sibling parent bobef <bobef_member pathlink.com> writes:
It think this behavior is not only *strange* but stupid, I believe, and it
differs from all other [] behavior. If it was normal, [] would be test
(+retrieve) value
and []= would be insert. It is clear and straight forward... And if it stays
this way it should be mentioned with BIG asterix in the docs because it is
different from all other D and noone would think it will behave like that...

In article <opsoxq1ipy6yjbe6 sandmann.maerchenwald.net>, Uwe Salomon says...

 Let's just say, I'd like to hear the motivations for the current
 behavior (again)!


 I'd like to hear these too , is any one actually _for_ this ?


Yes. I am. This is like it's done in Qt, and I think it is quite useful.  
There are two operators for AAs:

[]   - insert (+retrieve) value
in   - test (+retrieve) value

As you can see, there already is an operator for looking up a value (it  
returns a pointer to the value, i think, or null if it isn't in the AA).  
So you can change it if it is found, without looking it up again. If you  
would change the behaviour of [], there would be no operator for "give me  
the value to key X, or the default if there isn't an X in the map". It is  
very important to have an operator for every of these use-cases, because  
all workarounds are much slower and would thus render the AA useless for  
programmers needing the speed.

Ciao
uwe
Apr 10 2005