From: Bjorn.Karlsson_at_[hidden]
Date: 2002-06-18 08:18:24
> From: James Curran [mailto:JamesCurran_at_[hidden]]
> Sent: den 18 juni 2002 13:04
> To: boost_at_[hidden]
> Subject: [boost] Re: Future of share_ptr
>
>
> RE: [boost] Future of share_ptr What was the reaction at
> the Curacao
> meeting?
This is an excerpt from a note posted by Beman after the meeting:
--- smart pointer proposal status ---
[Curacao: The LWG expressed serious concerns about the proposal, and about
other smart pointer issues:
* Because user needs are so varied, Standard Library smart pointers should
support a full feature model, including user supplied behavior. A
policy-based design is seen as the only candidate likely to meet this
criteria.
* Because of the need for a single smart pointer to recommend for everyday
use, and for interoperability between third-party libraries, shared_ptr is
seen as a likely candidate for standardization. The LWG is interested
primarily in the interface and with interoperability, although aware that
implementation might well be forwarded to a policy-based smart pointer.
* Standard Library smart pointers should be viewed as a whole to ensure
consistency and interoperability; thus the idea of unrelated proposals for
non-policy based and policy-based smart pointers meets much resistance.
* Proliferation of Standard Library smart pointers is a serious concern; if
a policy-based smart pointer and a compatible shared_ptr were available,
they would be preferred; scoped_ptr, scoped_array, and shared_array were
not viewed favorably by many LWG members.
* LWG members are very concerned that "you don't have to pay for what you
don't use." This is particularly true of memory; increased memory use due
to multiple inheritance or to accommodate weak_ptr, for example, is viewed
as a serious problem.
* LWG members are concerned about usability and flexibility of designs with
multiple template policy parameters. A single policy parameter, with
policy composition by chained inheritance, would seem to have usability,
flexibility, and inter-policy communication advantages.
* In a quick (no discussion of exact meaning of terms) straw poll, the vote
was 9 1/2 yes, 0 no, to the question of whether or not a policy-based smart
pointer should support arrays. (The 1/2 vote was from someone undecided.)
* There was a bit of discussion and show of hands on non-member versus
member functions. No clear guidance resulted; the existing use of member
functions in std::auto_ptr and the Boost smart pointers muddied the
question.
Note that the LWG is still considers many of these concerns as subject to
change, as proposals are refined.]
--- end ---
Bjorn