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