[boost] Re: Re: policy-based smart pointers are EVIL! (was: Intrusive smart pointer)

From: David B. Held (dheld_at_[hidden])
Date: 2002-05-03 10:13:17

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:009a01c1f29d$ce9086d0$1d00a8c0_at_pdimov2...
> [...]
> The other option is to keep shared_ptr as the interop, "non-free" smart
> pointer. As I said, it does not compete with smart_ptr. I don't see why
> should smart_ptr be artifically evolved to swallow shared_ptr and
> auto_ptr; I am not saying that it must not, I am saying that smart_ptr
> should have a clear design focus that should not be compromised by
> religious, nontechnical, attempts to "assimilate the competition." If the
> design calls for shared_ptr emulation, so be it.

I think as a matter of survival, it does, especially if the LWG ends up
agreeing with you, and decides that there ought to be two smart pointers,
one of them spelled "shared_ptr<X>" for simplicity, and the other
decorated with the kitchen sink.

Given the following notes from the Curacao meeting:

    * 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 standard-
    ization***. 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.

it seems that the only way for a policy-based pointer to survive
would be for it to work with shared_ptr.  How do you define
a conversion c'tor without emulating shared_ptr's behaviour?  It
needs to use shared_count, which pretty much fixes its implementation
to be more or less identical to shared_ptr.  And I read "compatible"
as "having the same interface".  So there you go.  A TPSP needs to
emulate shared_ptr whether it likes to or not.

Dave