Boost C++ Libraries: Ticket #2393: ptr_map_adapter::insert uses non-const key parameter

attachment set

anonymous — Thu, 09 Oct 2008 07:41:50 GMT

attachment → boost-1.36.0.ptr_map.patch

ptr_map_adapter insert parameter patch

status changed; resolution set

Thorsten Ottosen — Thu, 09 Oct 2008 08:05:44 GMT

status new → closed
resolution → invalid

This is not a bug. See the FAQ.

status, version, milestone changed; resolution deleted

gary.yund@… — Fri, 13 Aug 2010 15:06:21 GMT

status closed → reopened
version Boost 1.36.0 → Boost 1.43.0
resolution invalid
milestone Boost 1.37.0 → Boost 1.44.0

Replying to nesotto:

This is not a bug. See the FAQ.

I'm not sure I understand this rationale for not making it const according to the FAQ.

The insert method at some point will need to copy the string to assign the value in the map. The insert method can't assume ownership of the string because someone else may delete it at any time. By not guaranteeing it as const, users of this function are forced to either copy the string to a temporary string, and pass that in, or const_cast it, but then they are vulnerable to the implementation in changing it and can't guarantee to users of the routine that the string passed to them hasn't really been modified. I do understand the need to pass it by reference (as it should).

I guess the real question is how does constness affect exception handling & why would an insert function need to modify the key value?

Also, another thought... if the key is a string or any other type. POD's like int, float, char, double, etc. should probably be passed by value specified in an overloaded template, because storing a pointer to an 8,16,32 bit value is essentially doubling the amount of storage needed for that value. 32/64 bits for the pointer + the data.

Just trying to grasp an understanding for this rationale. Re-opening the ticket because I think it deserves another look. Thanks.

anonymous — Mon, 23 Aug 2010 13:04:04 GMT

The key is not modified.
The exception-safety we get by a non-const reference is not total, but probably better than nothing (if the expression returns an lvalue, then the expression might throw).'
One could make the parameter const for types that do not throw upon copy,but it still leaves the hole when the expression throws. Here we must trust the programmer until a better solution arives.
An lvalue often forces the programmer to store the object in a local variable, thus increasin exception-safety in the sense that the expression involving the key cannot throw.

-Thorsten

status changed; resolution set

Thorsten Ottosen — Thu, 31 Mar 2011 20:21:32 GMT

status reopened → closed
resolution → invalid