The key issue here is that std::vector trying to offer an exception safety guarantee for as many operations as possible, but in order to do this, it needs support on the type of element. For push_back , emplace_back and friends, the main problem is what happens if redistribution is required, since existing elements need to be copied / moved to a new repository.
The corresponding standard wording is given in [23.3.6.5p1]:
Notes: causes redistribution if the new size is larger than the old. If redistribution does not occur, all iterators and references before the entry point remains valid. If an exception is selected other than the copy constructor, moving the constructor, assigning an operator or move assignment operator to T or any InputIterator operation has no effects. If the exception is the insertion of one element at the end and T is CopyInsertable or is_nothrow_move_constructible<T>::value true , there is no effect. Otherwise, if the exception is not CopyInsertable move constructor, not CopyInsertable T , the effects are undefined.
(The original wording in C ++ 11 was refined by LWG 2252. )
Note that is_nothrow_move_constructible<T>::value == true does not necessarily mean that T has a move constructor noexcept ; a noexcept copy constructor accepting const T& will also do.
In practice, this means that conceptually, the vector implementation usually tries to generate code for one of the following solutions for copying / moving existing elements to the new storage in descending order of preference ( T is the type of element, and we are interested in class types here):
- If
T has a useful (existing, non-deleted, non-ambiguous, accessible, etc.) noexcept move noexcept , use it; exceptions cannot be thrown when building items in the new repository, so there is no need to return to the previous state. - Otherwise, if
T has a convenient copy constructor, noexcept or not, which accepts const T& , use this; even if copying throws an exception, we can return to the previous state, since the originals still exist, unmodified. - Otherwise, if
T has a useful move constructor that can throw exceptions, use this; however, a strong guarantee of the safety of exceptions can no longer be offered. - Otherwise, the code does not compile.
The above can be achieved with std::move_if_noexcept or something similar.
Let's see what Category offers in terms of constructors. None is declared explicitly, so the default constructor, copy constructor, and move constructor are implicitly declared.
The copy constructor uses the appropriate member copy constructors:
data is std::vector , and the vector copy constructor cannot be noexcept (usually you need to allocate new memory), so the Category copy constructor cannot be noexcept no matter what the QString is.- The constructor definition
std::vector<std::unique_ptr<int>> copy calls the std::unique_ptr<int> copy constructor, which is explicitly deleted, but this only affects the definition, which is created only when necessary. Declaration is needed to resolve overloads, so Category has an implicitly declared copy constructor that will cause a compilation error when called.
Move constructor:
std::vector has a noexcept move noexcept (see note below), so data not a problem.- Older versions of
QString (prior to Qt 5.2):- The move constructor is not explicitly declared (see Praetorian comment above ), therefore, since there is an explicitly declared copy constructor, the move constructor will not be declared implicitly at all.
- Defining an implicitly declared
Category constructor will use the QString copy constructor, which takes const QString& , which can be bound to rvalues (constructors for subobjects are selected using overload resolution). - In these older versions, the
QString copy constructor is not specified as noexcept , so the Category move constructor cannot be noexcept .
- Since Qt 5.2,
QString has an explicitly declared move constructor that will be used by the Category move constructor. However, before Qt 5.5, the QString move constructor was not noexcept , so the Category move constructor could not be noexcept . - Since Qt 5.5, the
QString move constructor is listed as noexcept , so the Category move constructor is also noexcept .
Note that Category has a move constructor in all cases, but it may not be moved by name , and it may not be noexcept .
Given all of the above, we can see that categories.emplace_back() will not generate code that uses the Category move constructor when using Qt 4 (OP case), because it is not noexcept . (Of course, in this case there are no existing elements, but the solution for executing emplace_back time must include the path to the code that handles the general case, and this code must compile.) Thus, the generated code calls the Category copy constructor, which causes a compilation error .
The solution is to create a move constructor for the Category and mark it noexcept (otherwise it will not help). QString uses copy-on-write anyway, so it is unlikely to throw when copying.
Something like this should work:
class Category { std::vector<std::unique_ptr<int>> data; QString name; public: Category() = default; Category(const Category&) = default; Category(Category&& c) noexcept : data(std::move(c.data)), name(std::move(c.name)) { }
This will start the QString move constructor if declared, and use the copy constructor otherwise (just like the implicitly declared move constructor). Now that constructors are declared by the user, you must also consider assignment operators.
Explanations for bullets 1, 3 and 4 in the question should now be pretty clear. Bullet 2 (make data just one unique_ptr<int> ) is more interesting:
unique_ptr has a remote copy instance; this causes the Category implicitly declared copy constructor to also be defined as remote as well.Category The move constructor is still declared above (not noexcept in the case of OP).- This means that the code generated for
emplace_back cannot use the Category copy constructor, so it must use the move constructor even if it can be selected (see the first section above). The code compiles, but it no longer offers a reliable security guarantee.
Note: vector The move constructor has only recently been specified as noexcept in the standard after C ++ 14 as a result of the adoption of N4258 in a working draft. In practice, however, both libstdC ++ and libC ++ have provided the noexcept move noexcept for vector since C ++ 0x; implementation allows you to strengthen the specification of the exception compared to the standard specification, so OK.
libC ++ actually uses noexcept(is_nothrow_move_constructible<allocator_type>::value) for C ++ 14 and below, but distributors must be intransitive and copied constructive with C ++ 11 (table 28 in [17.6.3.5]), so that redundancy for Standard- Suitable valves.
Note (updated): The discussion of the strong exception security guarantee does not apply to the standard library implementation shipped with MSVC up to version 2017: until Visual Studio 2015 Update 3 is updated, it always tries to move regardless of the noexcept specification.
According to this blog post from Stephan T. Lavavej, the implementation in MSVC 2017 has been redesigned and now behaves correctly as described above.
Standard references apply to Draft N4567, unless otherwise specified.