
Not to be contentious, but IMHO it seems that shared_ptr's reach has exceeded its grasp. After looking thoroughly into shared_ptr, I have major doubts about what appear to be design-induced inefficiencies: 1. There is no support for "introducing" shared_ptr to a type T such that shared_ptr would use an intrusively managed count. This is just about required in my book for practicle use of reference counting in large applications. I see intrusive_ptr<>, but this would not help template code that wanted to share ownership of some type T; should it use shared_ptr<T> or intrusive_ptr<T>? Only type T knows. 2. The idea of weak_ptr seems to force external reference counting and a mutex (of some sort) to guard the counter(s). If there is a safe way to use lock-free counting and still get the assurances of weak_ptr::lock, I'm not clever enough to see it. Also, I can see no hope of tuning shared_ptr<T> for intrusive counting and keep weak_ptr. To me, this feature is worth no more than sizeof(ref_count) per object and no hidden locks, at least on platforms that support atomic integer operations. weak_ptr<T> would not be available if shared_ptr<T> was based on intrusion, again unless someone more clever than I could find a way to do so that wouldn't burden code that doesn't use weak_ptr. 3. The deleter feature also adds virtual function bloat as well as more per-object overhead. To me, this kind of overhead would preclude use of shared_ptr in all by the most trivial applications. The problem again is that this is not something that can be avoided by shunning the use of some features. For example, if the deleter where part of a shared_ptr<void> specialization or something. 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." My $2e-02, Don ===== __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

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
participants (2)
-
Beman Dawes
-
Don G