Re: [Boost-bugs] [Boost C++ Libraries] #2393: ptr_map_adapter::insert uses non-const key parameter

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #2393: ptr_map_adapter::insert uses non-const key parameter
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-08-13 15:06:21


#2393: ptr_map_adapter::insert uses non-const key parameter
---------------------------+------------------------------------------------
  Reporter: anonymous | Owner: nesotto
      Type: Patches | Status: reopened
 Milestone: Boost 1.44.0 | Component: ptr_container
   Version: Boost 1.43.0 | Severity: Problem
Resolution: | Keywords:
---------------------------+------------------------------------------------
Changes (by gary.yund@…):

  * status: closed => reopened
  * version: Boost 1.36.0 => Boost 1.43.0
  * resolution: invalid =>
  * milestone: Boost 1.37.0 => Boost 1.44.0

Comment:

 Replying to [comment:1 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.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/2393#comment:2>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:04 UTC