strange std::map behavior

A good interface is one where your guess as to what things do is what they actually do. A large part of that is function naming too. Unfortunately the [] convenience function for a map doesn't have a descriptive name, and many people that guess its behaviour, get it wrong.
That said, it is terribly convenient, and many of us would be lost without it.

Always conduct the documentation first

Unfortunately the [] convenience function for a map doesn't have a descriptive name, and many people that guess its behaviour, get it wrong.

The interface design of vector:perator[] is perfectly intuitive for people who learned C arrays. Migrating C programmers have always been an important target for the designers of C++ and its standard library.

Originally Posted by CornedBee

The interface design of vector:: operator[] is perfectly intuitive for people who learned C arrays. Migrating C programmers have always been an important target for the designers of C++ and its standard library.

Oh certainly the vector one is, but I was talking about the map one.
And in all fairness, if all your code ever does is uses the [] operator on the map, in-effect treating it like an ultra large array, then it pretty much will act like just an ultra large array.

Oh certainly the vector one is, but I was talking about the map one.

That's a more weird case. map's [] works the way it does because there is simply no other way it could work. It's not exactly intuitive to newbs, but when you think it through, you find that there's no alternative.

Well, it could throw an exception if the key doesn't exist, so it was an interface design decision to make it work as it does?

Anyway, when comparing C++ to Python, then the good practices concerning use of exception is rather different. In Python, heavy usage of exception is encouraged. It is encouraged to try an operation without previous checks, catch any possible exceptions and carry on. For example, even the for construct uses exceptions under the hood to stop looping, if I'm not mistaken.

In addition the dict type is probably not quite the same as std::map in C++. In C++ it is just an associative container. In Python it is a built-in object, there's even special syntax for unpacking dictionaries in function arguments, so its usage seems a bit different.

Indeed - exceptions are very expensive in many C++ implementations, and the standard explicitly encourages implementors to optimize the non-exception case at the expense of the exception case. (Or was it the Speed TR? Not sure.)

If [] threw an exception on a missing element, you couldn't do this:

Code:

m[key] = value;

and have it set the map element at key to value, no matter if it's already there or not.

If [] threw an exception on a missing element, you couldn't do this:

and have it set the map element at key to value, no matter if it's already there or not.

Of course, but it throwing an exception on a missing element implies that that (cumbersome) behaviour is intended. It becomes about as convenient as using find() and insert(), with possibly worse performance due to the exception handling, but that is different from saying that there is no alternative.

hats off to the strange behavior of C++ in the name of ... i don't know whom

give an out of range index to [] operator of vector class and it gives garbage!
give a non-existing key to [] operator of map class it creates stupid stuff!

C++ is an excellent language, you can do everything, anyway you like, with it.
but the mind of the people who have already implemented so much stuff (and ready availability of such stuff is a must), i can't understand what they were thinking of!

but the mind of the people who have already implemented so much stuff (and ready availability of such stuff is a must), i can't understand what they were thinking of!

That's easy:

give an out of range index to [] operator of vector class and it gives garbage!

They were thinking of efficiency, and provided the alternative of at() if efficiency is not desired.

give a non-existing key to [] operator of map class it creates stupid stuff!

As we have been trying to tell you, it does not create stupid stuff. It creates an object using the default constructor. If this is stupid, it implies that your usage of it is stupid, since you should use member find() instead.

why there is not a has_key() function? so sad

why there is not a has_key() function?

has_key() is equivalent to m.find(key) != m.end(), for a map named m.

Originally Posted by manav

why there is not a has_key() function? so sad

Isn't that what "find()" is for?

--
Mats

thanks!
there are kludgey ways. alright. there are ways around every problem. ok.
but the thinking of original implementers is still lacking ... i feel

but the thinking of original implementers is still lacking ... i feel

Explain why you think the thinking of the library designers is lacking.

Note that find() is more powerful than a has_key() function. Not only that, but the use case of not inserting an element if one exists implies searching for an element with that key. It is a waste of time to check if the map has a key, and then search for the element with that key, because the act of checking if the map has a key involves searching for it.