Andrei Alexandrescu said: > "Beman Dawes" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> At 04:25 PM 1/24/2003, Jeffrey Yasskin wrote: >> >> >Just out of curiosity, which boost libraries are likely to be >> proposed > to >> >the committee? >> >> See http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1397.html > > This is yet another bad PR move, but then I thought, if voicing an > opinion around here constitutes a problem, then the problem is not mine. > So here goes.
Voicing an opinion should never be a "bad PR move", at least if you voice your opinion in a tactful manner. And I think a large portion (most? all?) of Boost would love to hear your opinion on nearly anything you think needs voicing. > The smart pointer proposal is unconvincing to me. This, of course, comes > at no surprise. There's some conjecture in the reference document at > http://www.boost.org/libs/smart_ptr/shared_ptr.htm such as "The support > for custom deallocators does not impose significant overhead" or "My > opinion is that the added functionality is worth the cost" etc. Not what > one would like to hear about a one-size-fits-most standard library > implementation. Not sure if this is the proper forum for that particular opinion. shared_ptr is already part of Boost, so the opinions stated make little difference to Boost users/developers. Seems this opinion would be better expressed in the committee meetings (since I know you're a member) or to the committee members (for those that aren't members). > On to the FAQ. (I will skip over the first three Q&A with which I > totally disagree.) > > Q.Why doesn't shared_ptr provide a release() function? > A.shared_ptr cannot give away ownership unless it's unique() because the > other copy will still destroy the object. > > The answer doesn't answer the question. The next natural question is, > "ok, but if the pointer is unique(), can I benefit of a release() > function that returns a bool telling me whether the release worked or > not?" This particular answer has always bothered me as well. It would be possible to have release() *always* work, simply by keeping a flag that indicates the request, and having the 0-ref-count condition delete *only* the ref-count. Note that I'm not claiming that this, or your suggestion, are the proper design choices, only that the answer doesn't address either alternative. > It turns out that in COM the need of relinquishing ownership back to the > system (or another entity) is a common case. Has anyone used shared_ptr > with COM extensively? No, but the suggested bridge seems to me like it should cover all cases. Do you have a specific use case where it fails? > Q. Why doesn't shared_ptr provide (your pet feature here)? > A. Because (your pet feature here) would mandate a reference counted > implementation or a linked list implementation, or some other specific > implementation. This is not the intent. > > This is a presupposition. Someone wants to mandate lazy > initialization/specific dereference testing/specific initialization > testing/tons others. Would any of these require a refcounted/reflinked > implementation? Also a valid question, IMHO. I understand why this Q/A is there, but it dismisses too many things with out a proper response, or as you put it, presumes too much. William E. Kempf [EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
