Re: [boost] shared_ptr doubts

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-01-29 17:40:51

At 12:02 PM 1/29/2005, Don G wrote:

 >... [various doubts about shared_ptr features]
 >
 >While I like the aesthetics of these features, I can see little
 >practicle need for them given their cost. In other words, I would
 >trade both of them for the knoweldge that I could "use the
 >shared_ptr, Luke" without concern for such bloat. Herb Sutter
 >advocated this position in a recent C++ User Journal article, which
 >is what sparked my curiousity in the first place.
 >
 >Again, perhaps I've missed something profound and fundamental in the
 >specification of shared_ptr that would allow for these features and a
 >highly effecient implementation of basic reference counting. As I see
 >it, I will have to keep my own counted_ptr which does "just the
 >counting, ma'am."

You are seeing the trees but missing the forest.

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.

But sometimes a single general-purpose smart pointer is needed. 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. Or in cases where various efficiency concerns are nowhere near as 
important as using a well-known, well-understood, and soon standardized 
smart pointer.

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. 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.

All IMO, of course!

--Beman