|
Boost : |
From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-05-03 14:35:46
After heaving read mostly all the messages regarding smart pointers (but
being too busy to participate until now), here are my thoughts:
> I would like to see people comment on the various questions:
>
> 1. Is a policy-based smart pointer still worth pursuing, or are there too
> many
> contentious issues that will never get resolved?
>
I think that it is not only still worth pursing but also required.
> 2. If a policy-based smart pointer *is* worth pursuing, is
> boost::loki::smart_ptr
> heading in the right direction? Is there a better candidate? Are there
> specific
> changes that could be made that would make it better?
>
IMO, boost::loki::smart_ptr is on the right path.
There are some issues to resolve, such as the way to arrange policies
(MI,Linear,Mixer,Adaptor, etc...), but these are secondary.
> 3. Which is best for Boost, and which is best for a library proposal?
> A) just shared_ptr
> B) just smart_ptr
> C) shared_ptr + smart_ptr
> D) other
>
For boost, and aimed at an eventual library proposal, I would like to see:
smart_ptr<> (policy-based)
shared_ptr,shared_array,intrusive_ptr,mt_shared_ptr,mt_shared_array,mt_intru
sive_ptr
IOWs, I think that a policy-based smart ptr is required as a basic building
bloc, which could be used non-locally if policy-agreement is achieved.
For default library interoperability and ordinary usage, I think we should
also provide a small set of single-parameter and fixed template-id options,
which would be -in Andrei's words- points in the design space; although not
just any points: representative points of ordinary practices.
The particular set I just presented is off the top of my head. I've divided
the design space in mt/non-mt, and within each half I identified 3 usual
needs for free-store allocated objects. Other fixed (ordinary) arrangements
could be considered, such as resource-oriented pointers, management of
non-heap objects, etc...
The bottom line is that I don't think that a policy-based design, which
gives maximum flexibility, should imply that well-though packages shouldn't
also be provided.
Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk