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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-28 08:22:10

Andrei Alexandrescu said:
> "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.

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
wekempf_at_[hidden]