"Andrei Alexandrescu" <[EMAIL PROTECTED]> wrote in message b14cq2$2km$[EMAIL PROTECTED]">news:b14cq2$2km$[EMAIL PROTECTED]... > "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.
PR stands for public relations AFAIK. Why is it a PR move ? If you think it is a bad PR move, why is it "another bad PR move", ie. what was the previous bad PR move ? > > 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. > > 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?" > > 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? I agree with you here. I think that one should theoretically be able to release a shared_ptr if there are no other copies of it around. However could you explain further the situation(s) in which this is likely to occur ? I understand COM but normally one uses a smart pointer with COM that is tied into the referencing counting mechanism of the COM interface to which the pointer is referring. Without getting too deeply into a discussion of COM, I would be reticent to use a general smart pointer mechanism with it but would use one designed specifically to work with COM interfaces such as those provided by Microsoft and Borland with their C++ offerings. I don't doubt that a generalized smart pointer that worked correctly with COM might be useful, but then should we consider CORBA and any other generalized object-oriented technologies in the mix. Where does one stop ? > > 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? Perhaps this has already been done, or perhaps you mean others to look at your own Loki smart pointer to understand what you think is missing from Boost shared_ptr, but I think you need to either specify what you believe are the specific weaknesses of the Boost shared_ptr class, present your own smart pointer to Boost as a better alternative within the Boost library, or present your own smart pointer to the C++ committee as a better or additional alternative to the Boost shared_ptr. Your last paragraph is not an argument for anything because one can not guess what "tons others" means. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
