Is it safe to use emplace_back with a container of unique_ptrs?

Question

Consider the following:

std::vector<std::unique_ptr<int>> ptrsToInts;
ptrsToInts.emplace_back(new int);

If reallocation occurs in the vector, and that fails (throwing std::bad_alloc), am I "safe" or will I leak an int?

C++11 23.3.6.5 [vector.modifiers]/1 says:

If an exception is thrown other than by the copy constructor, move constructor, assignment operator, or move assignment operator of T or by any InputIterator operation there are no effects.

which seems to indicate that this is a potential problem. That is, if there are "no effects", then no unique_ptr ever was constructed, and therefore the destructor behavior one would rely on to delete that pointer would not occur. (Which might indicate that emplace_back should be banned for containers of unique_ptrs)

Knudsen

Good point. This has inspired me to drop my use of new entirely in favor of std::make_unique, so that I can know every allocation ends up on a smart pointer from the get-go. – Harrisharrisburg

I noted this pitfall in a comment here: #3284278 – Cuirass

Answer 1

If reallocation is required and it fails, then yes, your object never went into the container and will thus be lost.

However, it should be noted that this is pure user error. emplace_back should not be "banned" for containers of unique_ptr, because there are perfectly safe ways of doing this (such as reserveing the space beforehand, so you know it will always be there). Also, you can pass in whole unique_ptrs, since it's perfectly capable of using a move constructor.

So really, it's your fault for not properly wrapping your non-RAII object (the int*) in a RAII object before the point where you could throw exceptions.

Whitefly

Ah -- but the object never made it in. Emplacement constructs the object in-place inside the vector memory block itself. What's being passed in is a pointer, not a unique_ptr. Sure, the pointer is destroyed, but do I have the guarantee that the destructor of unique_ptr runs and deletes the pointer? – Knudsen

Actually the fact that the emplace is a no-op for an exception rather speaks for the int not getting deleted properly, as its allocation happens completely outside the emplace, whereas the construction of the (deallocating) smart pointer happens inside. – Startling

Erm, since when does there need to be "fault" assigned here? As for there being "perfectly safe" ways to do this, sure, there are "safe" ways to do it. But if you force use of a move constructor you might as well just use push_back instead, because it enforces the correct behavior in all cases. – Knudsen

@BillyONeal: "But if you force use of a move constructor you might as well just use push_back instead." But then you have to pick between the two, rather than always just using emplace_back. And who wants the hassle of that? Just use the same one everywhere and make the copy/move explicit. One rule is easier to remember than two. – Whitefly

@BillyONeal: As for "fault", you suggested that this should be "banned" (whatever that means). That means you think that the language/API is wrong and should be avoided. Thus, if you encounter into this issue, it is the language/API's fault rather than the programmer. If it's just user error, there's no reason to ban it, right? – Whitefly

@Nicol: Hmm... Not what I meant by banned. Let's say "strongly discouraged". – Knudsen