Why are you using delete so often in C++...? 'delete' should be rare in your code.
You're exactly right. But there are multiple complications:
- unique_ptr and shared_ptr are only available in C++11 onwards, we're still to migrate to a new compiler
- auto_ptr is a joke [1]
- I've got to live with `delete` in our gargantuan codebase at work
- I could (and should) use boost's smart pointers, and indeed I do when possible. But I admit I sometimes even forget to use those and end up with naked pointers instead.
And if you really can't, and you need a container that automatically frees its contents when destroyed, just stick it in a STL vector.
std::unique_ptr (or its predecessor, boost:scoped_ptr if you don't have access to C++11) should be used all over the place. There are many reasons why you may not want by-value containment of objects, and std::unique_ptr gives you object-lifetime ownership of pointers.
I'm interested in reading them actually, would you mind listing them?
Polymorphism - a value object is always exactly its static type, but you can substitute in different derived types for a unique_ptr. The previously-held object is automatically destroyed when you do this. This is essential for the State and Strategy patterns.
Reassignment/swap - reassigning a unique_ptr destroys its previous value and transfers ownership of the new one. Reassigning a value object invokes operator=. The former can (sometimes, not always) be faster than the latter - think about cases where you just want a quick pointer swap inside the object, rather than having to shuffle all the bits in a large struct around.
Release - unique_ptr has a member function to release ownership of the object, while this concept doesn't apply to value objects. Where might this be useful? Well, imagine trying to achieve exception safety inside a factory function with complex construction logic, and then transferring ownership to the caller. It's common to immediately assign the new object to a unique_ptr upon construction (so if an exception is ever thrown, it is destroyed properly), perform your logic, and then return ptr.release().
#include <iostream>
#include <memory>
std::unique_ptr<int> foo() {
std::unique_ptr<int> x(new int(42));
return x;
}
int main() {
std::cout << *foo();
}
std::unique_ptr<int> foo(std::unique_ptr<int> x) {
return x;
}
std::unique_ptr<int> foo(bool b) {
std::unique_ptr<int> x(new int(42));
std::unique_ptr<int> y(new int(17));
return b ? x : y;
}You could imagine another example where the goal of the factory function is to construct an object and then set one of two or more other owned pointers to the value. You still want something to hold ownership of the pointer, but don't know its eventual home until after some complicated logic finishes, and don't want to pay the copy constructor cost. That might make a better illustration (or technically, you'd use operator= instead of release(), but same basic point).
> Nullability
What do you think of boost::optional?
> Polymorphism
unique_ptr is probably the wrong choice here. You should be using ptr_vector: http://stackoverflow.com/questions/9469968
> Reassignment/swap
The indirection and heap (de)allocation also imposes a slowdown, though. Have you actually experienced this to be worth it in some cases, or is this just a guess?
> Release
I don't think this is a valid reason...? This is a pretty common idiom for releasing value types:
Type().swap(existing); // release 'existing'
But aesthetically, I've learned to distrust any code that likes to throw objects around the design by pointer. It's untidy, and leads to needless abstraction and poor coupling. The time you spend trying to fit your objects into by-value composition is time you save later not having to untangle your knots of pointers.
The whole notion of having to carefully manage ownership via syntax (seriously: try explaining to a python programmer why they have to use this insane "unique" thing just to store a reference to something) instead of via structure (put the object inside its owner) is just vile, aesthetically. And it's something that C++ nuts tend to be really bad about.
You don't always have control over the code you are writing, an example that comes to my mind quickly is ffmpeg.
Smart pointers are not a panacea.