> Obviously you missed the delights of reading Karl May's Winnetou when you > were a kid :o).
:-) Yes, I've missed this. I started to read in English not too long time ago. [snip] > Looks great. However, all these behaviors can be, and most were, trivially > implemented as policies of SmartPtr, while benefitting of all the extra > amenities, which all your pointers are lacking. > Seems, however, that I need to refocus my efforts of convincing people that > SmartPtr is the way to go and design within its framework - the kavorka of > implementing one's own pet smart pointer is way too overwhelming :o). > > Andrei Andrei, please don't take me wrong. I felt myself inspired after reading your Modern C++ Design and some articles in CUJ. But I'm also completely agree with rationale given in QA1-3 at http://www.boost.org/libs/smart_ptr/shared_ptr.htm#FAQ (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) One of great advantages of Loki::SmartPtr is on-the-fly construction of different smart pointer types. But not all libraries can be completely implemented in templates (for which Loki::SmartPtr currently is the way of choice). Consider the following example: struct EventSource { virtual void registerListener(const smart_ptr<Listener> &) = 0; } With policy-based smart pointer this method either forces clients to use a specific set of policies, or to perform smart pointer type conversion, that may be expensive or not available at all. The most obvious advantage of my implementation is that intrusive, semi-intrusive and non-intrusive ref. counting are all transparently (and with no performance penalty) supported by the ONLY class refc_ptr<T>. Therefore with refc_ptr<> the registerListener() method in the above example doesn't need to care about exact type of allocation of an Listener object passed to it. Implementing of refc_ptr as a set of policies is also possible, but currently that seems to be overkill, both in unnecessary complexity and performance losses. Though this my opinion may change with time. Conclusion: IMO, policy-based implementations like Loki::SmartPtr<> and "fixed" ones like boost::shared_ptr<T> or my refc_ptr<T> serve different needs. Do I say something new? Hardly. Pavel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
