Thread: strange std::map behavior

map:perator[] public member function

T& operator[] ( const key_type& x );

Access element

If x matches the key of an element in the container, the function returns a reference to its mapped value.

If x does not match the key of any element in the container, the function inserts a new element with that key and returns a reference to its mapped value. Notice that this always increases the map size by one, even if no mapped value is assigned to the element (the element is constructed using its default constructor).

Why insert a new element and return a default value? Why not just raise an exception here? This really seems bad.

On a side note: Ditto behavior in Qt's QMap as well. Why such practice?

absolutely silly behavior i think.
thank god that Python handles it better

Code:

m = { 1:'uno', 2:'duo' }
print m[3]

Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    m[3]
KeyError: 3

Originally Posted by manav

Why insert a new element and return a default value? Why not just raise an exception here? This really seems bad.

How the heck could this work:

Code:

map[x] = y;

Unless map[x] returned a non-const reference? And how can map[x] possibly return a non-const reference without ensuring that the element exists?

>> And how can map[x] possibly return a non-const reference without ensuring that the element exists?
By throwing an exception if the element is not found?

But I agree that the current behavior makes sense and is very useful.

Originally Posted by Daved

>> And how can map[x] possibly return a non-const reference without ensuring that the element exists?
By throwing an exception if the element is not found?

That would render operator[] completely pointless. If you had to insert() an element before accessing it with operator[], then the only possible use of operator[] would be for lookup. I hardly see the point of even having an operator[] unless I can do this:

Code:

a[b] = c;

I'm not arguing with you about the usefulness of the feature, but you're point doesn't make sense. The vector class has similar syntax, and it isn't pointless.

Originally Posted by Daved

I'm not arguing with you about the usefulness of the feature, but you're point doesn't make sense. The vector class has similar syntax, and it isn't pointless.

Well, two responses to that:

1. For std::vector, operator[] is much more necessary than for std::map. A vector inherently "keys" its contents by their indices. Whereas with std::map, operator[] exists only for convenience, and the container would still be quite usable without it.

2. The original argument was, should operator[] throw an exception when accessing an out-of-bounds key or index. The answer, for both std::vector and std::map, is no. It's not valid to go out of bounds on a vector, but it doesn't throw an exception when you do it.

It would be a completely valid interface if it did, though. The at() function throws an exception, why couldn't an operator[]?

Your first point backs me up. The operator[] exists only for convenience, so a slightly less convenient usage would not be pointless, just less convenient.

Originally Posted by Daved

It would be a completely valid interface if it did, though. The at() function throws an exception, why couldn't an operator[]?

Because the only difference between the two is whether it throws?

Your first point backs me up. The operator[] exists only for convenience, so a slightly less convenient usage would not be pointless, just less convenient.

Decreasing the convenience of a convenience function makes it not a convenience function anymore, IMHO, simply a redundant one.

EDIT: Eh, I have a feeling I'm being obnoxious.

Although using the operator[] in a vector can produce undefined behavior if the specified element does not exist.