Re: Making a smart pointer which works with incomplete types
* Juha Nieminen:
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?
Flexibility and ease of use.
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)?
A templated function.
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,
It may be that 56 bytes won't matter where there is a need for this pointer.
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).
Cache.
[snip]
(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.)
It's just the functionality chosen, having per-pointer deleter, which allows
having two or more shared_ptr<T> with different destruction behavior.
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?