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...

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...

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...

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...
> 
> 
> 

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...
>>
>>
>>
>>

> 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...
> >>
> >>
> >>
> >>

>> 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

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.

>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.

> 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