Re: [boost] shared_ptr doubts

From: Don G (dongryphon_at_[hidden])
Date: 2005-01-30 01:38:35

It is likely that we will simply just disagree on this, but I will at
make a stab at responding to your points.

> For some specific smart pointer applications, it is possible to
> design a  smart pointer that is more optimal than shared_ptr.
> That's what a policy-based smart pointer is all about, and
> hopefully we will soon have one in Boost. In the meantime, look
> at the Loki policy-based smart pointer.

I'm familiar with Alexandresu's book (even if I can't always remember
how to spell his name<g>), but...

> But sometimes a single general-purpose smart pointer is needed.

Yes! Although I am focused purely on reference counting smart
pointers. But...

> For example, as a standard type to communicate between libraries,
> including third-party libraries. Or to recommend generally to a
> wide-range of programmers, including those who might be confused
> by a plethora of choices.

Exactly.

> Or in cases where various efficiency concerns are nowhere near as
> important as using a well-known, well-understood, and soon
> standardized smart pointer.

Why can't we have both? I would suggest that a major reason STL is so
popular is that it paid careful attention to efficiency from its
inception. If std::vector had allocated several or nearly a dozen
extra machine words per object as shared_ptr does at times, I believe
things would have turned out differently.

The std containers offer what is needed to accomplish a well focused
task, allocating only the data necessary for that job and no more.
For example std::list need only allocate 2 pointers per object. If
Stepanov had gone on to add feature after feature that made this
number on par with shared_ptr, again, it likely would not have been
well received.

> The Colvin-Dimov shared_ptr design solves a far-broader range of
> smart pointer problems than any other proposed design. That's
> why it is the most commonly recommenced C++ smart pointer type
> in the world. That's why the C++ committee is standardizing it.

Please don't take my doubts the wrong way; I am not trying to "dis"
their fine work. If folks want to use it, that's fine. They should be
warned, but caveat emptor.

I am focused on the last statement above. As it sits, shared_ptr
simply goes too far and in so doing one must always ask "is
shared_ptr suitable in this case?" As a library author, this is often
an impossible question to answer, because it could depend on the use
to which the library is put. In other words, by adding all the
frills, shared_ptr actually reduces its scope of applicability.

> It isn't intended to replace all other smart pointers. No single
> smart pointer type can do that. So appreciate it for the many
> problems it solves, rather than worrying about the problems
> where another smart point would be more optimal.

Where is the standard smart pointer to which you refer? I can keep
writing my own (have been for many years, and kinda like it<g>), but
what I would really love to see is a pair of simple ones provided by
the standard library that accomplish just two jobs: delete it; and
delete it when the count drops to 0 (with some means for the count to
be internal to the object). If more smart pointers are added beyond
that, that would be great.

So far, both auto_ptr and soon shared_ptr fail at the K.I.S.S. test.
They set out to solve these two "simple" problems and got lost along
the way. A standard facility should not offer such surprises to
unsuspecting users. With auto_ptr we got "surprise! you thought I was
the owner, but it was that other guy that just left scope". With
shared_ptr we will have "surprise! here's that bad_alloc you've
always wanted".

If the current design is the way it will be (probably), can't we at
least have a warning label:

"WARNING: shared_ptr may allocate 40+ bytes per object (fine print:
depending on platform and multithread considerations, your mileage
may vary, etc.)"

Well, I'm no lawyer I guess... <g>

> All IMO, of course!

Likewise!

Best,
Don

=====

                
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250