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

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.

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

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

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.

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

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

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.

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

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