Necessary Maintenance #8378
Ensure all move constructors and assignment operators are noexcept
In order to gain the maximum benefit from move semantics with STL containers, all explicitly declared move constructors and assignment operators should be
noexcept. Otherwise, the copy operation may be selected instead even when a move might actually be reasonable.
#1 Updated by Christopher Green about 5 years ago
- Target version set to 2.01.00
- Estimated time set to 6.00 h
We should also make use of the type trait
std::is_nothrow_move_constructible where appropriate for the desired level of assurance that any given compiler is doing what we need.
A standalone test in e.g. cetlib might also be reasonable, as there is some uncertainty over whether an explicitly-declared "default" move constructor or operator honors the noexcept status of the explicit declaration or overrides it to be noexcept.
#4 Updated by Kyle Knoepfel over 4 years ago
- Status changed from Accepted to Resolved
- Assignee set to Kyle Knoepfel
art suite, explicit move constructors/assignment operators are provided for only three classes:
noexcept specifier is now included for the appropriate "move" special functions for
sqlite::stringstream, the single member type is
std::deque<std::string>, which is move-assignable but not move-constructible. The
sqlite::stringstream move constructor can therefore not be labeled as
noexcept. Although an
std::vector<std::string> is move-constructible, switching the data type container from an
std::deque to an
std::vector may result in other inefficiencies due to the frequent popping of the first container element. For that reason, I have kept the
std::deque container and added the
noexcept specifier to the move assignment operator.