Andrei Alexandrescu wrote: >> (in short: "Parameterization discourages users", "Template parameters >> affect the type", "Having a single pointer type is important for >> stable library interfaces". Sorry for possible out-of-context citation)
> Your agreement with the statements above would naturally lead you to NOT > define yet another smart pointer, but instead, to work on perfecting > shared_ptr. Convictions and actions should best work in agreement. "One > Pointer Type is Good" and "I Have One More Pointer Implementation For You > Guys to Look At" don't go together. So if you were to start work on a > project now, what smart pointer would you use for a stable library > interface? If you'd use yours, does it mean you consider it intrinsically > better than shared_ptr? I think many would disagree for a variety of > objective reasons. (Some of them I mentioned in a reply to shifted_ptr, and > if I'm not wrong they apply to your work as well.) Then you might say, yes, > it all depends on what the project's context is. Then I come and say, /my > point exactly/. boost::shared_ptr must retain compatiblility with older versions. It can not be turned to another ways without harming many current users. I tried to write a more generic implementation that still replicates the strongest features of shared_ptr. For example, refc_ptr supports true intrusive ptrs with their little overhead. And it even supports semi-intrusive ptrs that are a clear replacement for intrusive ones. In this sense, yes, I think that refc_ptr is better than shared_ptr. I propose the idea. If it deserves living (that is still to be verified), I don't mind if it is implemented in some other smart pointer, for example policy-based one. > The whole purpose of smart_ptr is to devise a framework that makes it easy > for people like *you* to create their own smart pointers without having to > fight their way through all the syntactic and semantic gunk. Yes. In one of my projects I used 4 different types of smart pointers. 3 of them were std::auto_ptr, COM-ptr and a self-made library-specific ptr. It would be nice to have all these pointers in one framework like Loki::SmartPtr. But I still sure that pointers of the family like boost::shared_ptr (and my refc_ptr) are another story. Fighting through the syntactic, semantic and portability problems is challenge, but their functionality is even harder challenge. > Not that I don't think the fun aspect ain't important. I think this is my > main problem with Loki::SmartPtr: people seem to have more fun writing > smart pointers from scratch, than writing policies for it. If that persists > over time, then by all means Loki::SmartPtr ain't that cool. Seriously: fun > *is* important :o). :-) This my refc_ptr is about 2 years old. I improved it from time to time, after looking to boost, or reading Modern C++ Design. All this were for my own pleasure, you are right. For me your Loki::SmartPtr was rather a collection of well-defined considerations and hints. Most probably, I am not alone in this... I think you also designed Loki::SmartPtr mostly for your own fun :-). Pavel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost