Ebenezer said:
I agreed with Bjarne scolding some of the other panel
members for talking at length about shared_ptr. Bjarne
said he thinks of shared_ptr as something to be used "last".
That's also my experience. I program quite a lot in C++ as my payjob,
and *extremely* seldom do I have the need for shared_ptr or anything
equivalent.
If you have the need for shared_ptr that means you are allocating
objects individually with 'new'. Of course it may depend on the type
of application, but in practice I have noticed that needing to do so
is quite rare. In the vast majority of cases handling objects by value
is enough. If dynamic memory allocation is needed, it's usually needed
en masse, in which case you usually don't allocate the objects
individually with explicit 'new's, but instead you use one of the
standard library containers.
Perhaps GUI programming is something where allocating individual,
polymorphic objects is needed. OTOH in many cases you will usually be
using a GUI library which in itself provides the means to manage those
allocated objects...
One of the problems with shared_ptr is that it's very large in size,
compared to what it's "emulating", ie. pointers. If you create a shared_ptr
and give it an allocated object, it will take typically as much memory
as a dozen of pointers or so. Also, shared_ptr typically makes a memory
allocation in itself, so the total amount of allocations has doubled.
If you are allocating a couple of objects then that doesn't matter, but
it might matter if you are allocating millions of them (in terms of both
memory consumption and speed).