Boost logo

Boost :

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

* 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

Note that the LWG is still considers many of these concerns as subject to
change, as proposals are refined.]

--- end ---


Boost list run by bdawes at, gregod at, cpdaniel at, john at