Re: [boost] Re: Deadline for the Standard Library Technical Report

From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2003-01-27 19:28:06

At 03:47 PM 1/27/2003, Andrei Alexandrescu wrote:
>"Beman Dawes" <bdawes_at_[hidden]> wrote in message
>news:4.3.2.7.2.20030125135225.0226db40_at_mailhost.esva.net...
>> 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.

It's not a problem at all, so far as I'm concerned.

>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.

What would you like to hear?

>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?"

That's a suggestion worth considering.  Perhaps on success
release() should return a pointer to the deleter function.

>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?

Yes, but the need never came up.

>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?

Probably not, and I agree the answer is inadequate.  The honest
answer for any given feature would depend on whether it was ever
proposed and what came of the proposal.