ptr_map_adapter::insert uses non-const key parameter

[anonymous]

One of the insert functions appears to be missing a const qualifier for the key parameter.

[anonymous]

ptr_map_adapter insert parameter patch

[Thorsten Ottosen]

This is not a bug. See the FAQ.

[gary.yund@…]

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]

1. The key is not modified.
2. 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).'
3. 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.
4. 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