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

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2003-01-28 12:01:48

"David Abrahams" <dave_at_[hidden]> wrote in message
news:u7kcpjn7v.fsf_at_boost-consulting.com...
> "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?

See right below: :o)

> > 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 don't know about others, but when I read that three other pointers have
been removed from the proposal to make it palatable and that there's word
about a fourth, I start to doubt that shared_ptr is "so successful" and that
"in the great majority of cases it supplies all the features that users
need".

> 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'm very very happy to hear that, because the smart_ptr discussion at
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1397.html looks to me,
at least in comparison to all other discussions on the same page, more like
a agile plea based on subjective opinion that glosses over certain details,
rather than a technical, objective discussion.

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

My impression, on the contrary, was that the committee was much more willing
to look into a policy-based approach than into an inherently limited and
suboptimal design.

Ah, one thing. Binary compatibility and EXE/DLL issues are mentioned with
shared_ptr. For what I know, this is the very first component in the
Standard ever addresses this particular issue. Why not vector or string?
This might be a good precedent though.

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

I don't know about adding, but I press the "down" arrow only a few times and
what do I see? Only this year, some convo about shifted_ptr and
intrusive_ptr and cyclic_ptr. That's a mouthful already :o). If shared_ptr
covers 99% of use(r)s, there sure is a lot of fuss over the remaining 1%
:o).

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

Hurray! Thanks. Indeed it feels so very good to hear that from a member of
the committee. 'Coz the discussion on shared_ptr at
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1397.html does look to
me like... when there's no anchor, what to do? Sail!

:o))

Andrei