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