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

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-28 10:41:40

"Andrei Alexandrescu" <andrewalex_at_[hidden]> writes:

> There's also a contradiction in there. The document nicely continues "One of
> the reasons shared_ptr has been so successful is that in the great majority
> of cases it supplies all the features that users need." However, only two
> paragraphs below, in response to committee's "Proliferation of Standard
> Library smart pointers is a serious concern", we read the following:
> "scoped_ptr, scoped_array, and shared_array have been removed from the
> proposal."
>
> Am I the only one who sees the fly in the ointment?

Maybe.  What is the fly in this case?

> If shared_ptr is the factotum, how come there are some other pointers in
> boost that needed to be removed from the proposal? Why was their
> functionality deemed necessary? 

I think you fail to appreciate that the standards committee is
ultimately a somewhat different audience from the boost user
community.  The committee seems to be very much more conservative in
what it is willing to accept and consider.  A proposal for the
standard must be written with even greater rigor than Boost
documentation should be, and that can increase its length and
complexity.  I think there's a fear that a proposal containing 4 smart
pointer types (like one containing 5 template parameters <wink>) might
be hard enough for the committee to swallow that nothing at all would
be accepted.  That, at least, is my impression of why the other 3
smart pointer types were removed from the proposal.

> Also, what's the deal with weak_ptr? 

It's not really a pointer at all, though for a while we thought it was
(http://lists.boost.org/MailArchives/boost/msg34530.php).  In the end
it is still the best name anyone could come up with.

> And Sherlock Holmes would also like to ask, why are there new smart
> pointers added to boost on a regular basis?

Where does this question come from?  When was the last time we added a
new smart pointer?

> The committee also mentions that "LWG members are very concerned
> that "you don't have to pay for what you don't use." 

I was one of those.

> To this, the answer is "Issues related to weak_ptr are a side issue
> that can be resolved after the basic proposal is accepted. Also, be
> aware that different implementation techniques are possible, and
> they may make various speed vs space tradeoffs.  These choices are
> not mandated by the proposal."

I didn't find that part very satisfying, either.

> I think much more detail is fair at this point. Why resolve an issue
> after the proposal is accepted? What implementation techniques are
> possible, and what tradeoffs do they make? IMHO, the interface
> proposed (notably the custom deleter) does mandate quite some.

I agree with that.  The wording you cite sure seems like it's sweeping
aside valid concerns without truly addressing them.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution