"Pavel Vasiliev" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > 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.
Same here, I didn't speak *any* English until five years ago, but luckily, there was a Romanian edition :o). > 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) 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/. 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. Other posters mentioned undue complexity. I have to say that in a very egotistical manner I do take credit for what Dave Held mentioned: >SmartPtr is not gratuitously complex. >There are pretty good reasons for just about every line of code. I love it when someone who took the time to carefully look through the code and make efforts to improve (fix :o)) it can see this intent so clearly. Because indeed, unnecessary complexity (reason of /major/ peeves of mine with other libraries) is imho not a desirable quality at all. The introductory chapter "Techniques" of Modern C++ Design was written *last* (absolutely no exaggeration), and I made a point of putting there absolutely only stuff that had found practical use within the library, and to refer to those uses whenever introducing a technique. > 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. I believe this is not the case. I firmly believe that the exact behavior you support can be implemented as ONE ownership policy of SmartPtr (thus leading you to One Pointer Type) in a clearer manner (subjective criterion) and in fewer lines of code (objective criterion). Then you would keep the advantages and have no disadvantage, other than not having the fun of writing a smart pointer from the ground up. 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). Andrei _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
