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