[Boost-bugs] [Boost C++ Libraries] #11684: boost::string_ref lack of move constructor prevents efficient use in std::map

Subject: [Boost-bugs] [Boost C++ Libraries] #11684: boost::string_ref lack of move constructor prevents efficient use in std::map
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2015-09-25 12:56:15

#11684: boost::string_ref lack of move constructor prevents efficient use in
std::map
------------------------------+---------------------------
 Reporter:  banks@…           |      Owner:  no-maintainer
     Type:  Feature Requests  |     Status:  new
Milestone:  To Be Determined  |  Component:  utility
  Version:  Boost 1.59.0      |   Severity:  Optimization
 Keywords:                    |
------------------------------+---------------------------
 Not quite sure if this is a bug or a feature request given the statement
 in the docs:

 "string_ref does not define a move constructor nor a move-assignment
 operator because copying a string_ref is just a cheap as moving one."

 While that line makes total sense on it's own, it does have some
 undesirable (for me at least) consequences.

 It means that and class that may want to have `string_ref`s as members
 also can't be trivially move constructible even if their other members are
 expensive to copy.

 For custom classes that can be worked around by defining a move
 constructor that copies the `string_ref` members and moves the rest. But
 it's a limitation that can't be easily worked around for things like
 `std::pair` or `std::tuple` since even if you try specialising those
 templates, you can't redefine the explicitly defaulted move constructor.

 This is especially an issue for using `string_ref` as a key or value type
 in an associative container - in this case the `std::pair` type MUST be
 copied during insertion. If the other type in the pair is expensive to
 copy then `string_ref`s lack of move construction becomes an annoying
 performance barrier.

 Workarounds exist so it's hardly high priority, but it does reduce the
 reusability of `string_ref` and cause there to be cases where an
 alternative implementation might be used for essentially the same purpose
 to work around this issue. the cost of adding move construction seem low
 to me even if it might result in uninformed users using it spuriously
 under the assumption it will provide some performance increase over
 copying.

 To be clear the request is: '''please consider adding move
 constructor/assignment to''' `boost::string_ref`.

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