From lots of experience in C, I can say that either always or never owning something are the two good options. I may come back to this again later, but for now it seems we are trying to come up with elegant ways to do something that was always very hazardous in a slightly less dangerous way.

I felt like the biggest problem with having raw pointers everywhere was how easy it was to get confused about ownership. It may be a bit Draconian to always own something, but the inherent situation of “I’ve got a pointer to something, now let’s see, do I own this or not?” really can complicates an otherwise trivial interface.

Interesting ways of dealing with it tho — I’d been completely ignoring custom deleters until now.

Oh so the House class takes on the responsibility of choosing the right deleter. This is an interesting idea, hadn’t thought about it. This means that the caller is relieved from choosing the right deleter, but it should avoid passing a reference to an heap-allocated object to the second constructor then, right?

Right. I’ve added your remarks to the post, really grateful for your contributions!

Yes absolutely. That would fix it. One note though: unique_ptr’s don’t have copy constructors, so you’d need to explicitly move there.

With regard to your comment: sometimes you *have* to use raw pointers in constructors, like when using custom deleters, in all other cases you should prefer make_unique.

Right, it coud throw and this is an important point.
Isn’t the problem that

InstructionsUniquePtr(new Sketch, deleteInstructions)

is in the same expression as the call to constructor of House, rather than the new being in the call to constructor of the unique_ptr?
So the fix would be:

InstructionsUniquePtr instructions(new Sketch, deleteInstructions);
return House(instructions, getHouseNumber());

and no need to take the new out of the construction of the unique_ptr, what do you think?

Yes, of course you can talk about it.

Say for example the House constructor takes another argument, say, the house number.

return House(InstructionsUniquePtr(new Sketch, deleteInstructions), getHouseNumer());

Now, it is *possible* that `new Sketch` is executed, then getHouseNumber(), which may throw. Then the unique pointer is not created, and you have a memory leak.

When using a custom deleter, there’s no way arround this issue, but it should be mentioned nonetheless. More on this in Effective Modern C++ and function call evaltuation order on http://en.cppreference.com/w/cpp/language/operator_other#Built-in_function_call_operator.

Okay I see, that makes sense.

Yes I see. Anyway I find your idea great, and I will talk about it in Friday’s post, if you don’t mind.