|
Boost Users : |
From: Noel Yap (Noel.Yap_at_[hidden])
Date: 2005-02-15 11:09:06
Please direct me to a more appropriate list if this is too off topic:
It's come to my attention that our vendor's std::map<>::operator[] /always/ calls the default constructor of the key even when the key already exists in the map.
This is what they say:
It turned out to be a documentation bug. Our implementation is in sync
with the standard.
From 23.3.1.2 [lib.map.access]:
T& operator[](const key_type& x);
-1- Returns: (*((insert(make_pair(x, T()))).first)).second.
Notice the T() in the call to make_pair() above: that's an invocation of
the default ctor of the mapped type (i.e., Aoeu in the user's test
case). So the program behaves as expected. If you do not like this
behavior, replacing the expression map[16] in the program with map.find
(16)->second will avoid the construction of the unused temporary. I
modified the test case to incorporate this change.
My inclination is to say the standard is a spec, not an implementation. Allowing std::map<>::operator[] not to call the default constructor requires no more and promises no less than the spec. All this is true unless, of course, there's some order of
complexity issue I'm missing. But someone else had said, "an implementation has to have the same 'observable behaviour' as the abstract machine defined in the standard. Calling the default ctor definitely counts as observable behaviour, so I don't think
RW have any choice but to implement it this way".
What's the best place to get an official answer to the real intent of std::map<>::operator[]? Must it /always/ call the default constructor?
Thanks,
Noel
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net