Re: Making a smart pointer which works with incomplete types
Alf P. Steinbach wrote:
Yeah. Successive smart pointer instantiations can change the common
deleter func pointer.
They can, but they won't. The deleter function pointer is private to
the smart pointer class, so only the smart pointer itself can use it.
The pointer is also type-specific, so a new function pointer is created
by the compiler for each type with which the smart pointer is used.
If the only thing you have is the smart pointer constructor setting
the static deleter function pointer, what else can it point to besides
the deleter for the type? Nothing else.
Instead make the deleter function a template parameter.
What for? If you make it a mandatory template parameter that's very
inconvenient for the user because he would have to write an explicit
deleter for each single type he uses the smart pointer with. If the
template parameter is optional, it would require a default value. What
would be this default value (and how would it be different from what I
posted)?
But even better, forget about this premature optimization.
"Don't optimize prematurely" does not mean "deliberately make
inefficient code that hogs memory for no good reason". If making a more
efficient smart pointer is trivial and safe, I see absolutely no
compelling reason to not to do so. Why would I *deliberately* make the
smart pointer larger than necessary, if there is absolutely no reason to
do so?
For the few cases where this functionality is needed, e.g. PIMPL, just
use a boost::shared_ptr.
boost::shared_ptr is a horrendously inefficient memory hog. For
example, in a typical 32-bit linux system each instance of
boost::shared_ptr (which doesn't share the allocated object) consumes 56
bytes of memory, and all of its operations are slow (for example because
it allocates dynamically the payload data, and all of its operations are
thread-safe, even if no multithreading is done).
"56 bytes? No big deal." It indeed isn't a big deal if the number of
shared_ptr instances is relatively low compared to the total amount of
data used in the program, and its runtime overhead isn't either a big
deal if the shared_ptr instances are not created/destroyed/copied around
a lot, but only used to access the data they point to. Sure.
However, if you need to instantiate enormous amounts of smart pointers
and you perform a lot of copying and other operations to them, the
overhead can make a big difference in memory consumption and speed. When
you have millions of smart pointer instances, each single byte saved
counts. Whether your smart pointer consumes 56 bytes or 8 bytes can make
a difference of hundreds of megabytes of saved RAM consumption (RAM
which could be used for something more useful).
(In fact, I can't understand why boost::shared_ptr stores a deleter
function pointer in the payload it creates. I see absolutely no reason
why a static function pointer wouldn't work equally well. It would save
4/8 bytes per instance. Not much, but it's free and has no negative
consequences.)