Re: [boost] Smart pointer poll

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2002-05-05 11:37:04

Peter Dimov wrote:

> From: "David B. Held" <dheld_at_[hidden]>
> 
>>I would like to see people comment on the various questions:
>>
>>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
>>
> 
> What do 'shared_ptr' and 'smart_ptr' mean? Or, to be more specific: does
> 'shared_ptr' refer to an entity _named_ shared_ptr, to an entity that meets
> the specification in shared_ptr.htm, or both?

My interpretation of the question was that 'shared_ptr' refers to the
current semantics plus a distinguished name which is likely to be
"shared_ptr", although I would not put too much weight on the name. The
important thing is, IMO, that there is a distinguished name or maybe a
distinguished approach.

> Does 'smart_ptr' refer to a smart pointer framework, to a framework + some
> specific precanned policies (since 80% of the users won't write their own),
> or to a specific entity created using this framework?

My interpretation is that 'smart_ptr' refers to some form of
policy-based smart pointer, including a set of predefined policies which
may be combined and extended at user's needs. I probably includes some
form of preconfiguration, too (eg. default template parameters or
something equivalent).

> 3a. Should there be a single smart pointer type that is specifically
> designed for interoperability?

I think this question is still open. Maybe this is the way to go, maybe
it is not. There should be a clear and reasonably easy-to-use approach
for use when interoperability matters, that is, when people design
interfaces it should be obvious to use The One approach unless more
important considerations make special configurations necessary. Yes, I
know that this is pretty vague: This is intentional!

I read "single smart pointer type" as meaning a template name where
exactly one template parameter is specified and whose semantics are
identical across all instantiations (ie. there are no template
specializations). This may be a type like 'shared_ptr' or a
policy-based smart pointer where all but the first template parameter
are defaulted.

> 3b. Should there be a single smart pointer type that is specifically
> designed to cover a variety of common situations without requiring any user
> intervention or customization?

I think so. It may, however, simply use the default arguments of a
policy-based smart pointer.

> 3c. Is shared_ptr (the specification) the single smart pointer that meets
> 3a, 3b, or both?

The semantics seem to be a reasonable candidate for a default. Whether
this default is realized as a separate class is, IMO, still an open
issue.

> 3d. If it is, which is the best way to provide a smart pointer that meets
> that specification?
> 
> A) shared_ptr<T>, implementation details unspecified

Note, that this is only option in this list allowing type specific
reconfiguration of the semantics! This is, however, not a problem with
the other options just with the list of options :-)

> B) shared_ptr<T>, implementation required to be derived from a general
> pointer framework
> C) ptr<T>::shared
> D) smart_ptr<T> (defaulted parameters)
> E) smart_ptr<T, default_config>
> F) smart_ptr<T, A, B, C, D>

Personally, I can't answer this question, yet. A to D would meet my
desire for "reasonably easy-to-use". I would not like E and I think that
F is plain *EVIL* (for the purpose of interoperability; for use in
specific situation needing customization, it is the way to go, though).

I would like to see another dimension to this: Some form of type
specific customization, be it inferred from the type somehow, specified
via traits, or whatever. And, BTW, I accept that it is possible to
violate the ODR or other restrictions if this feature is not
appropriately used, even if the appropriate use is actually non-trivial:
sometimes the need for customization is more important than ease of use.

> 3e. Allow me to sneak a personal question. Should I bother with refining
> shared_ptr (the semantics) any further? I'd rather cut my losses now, to be
> blunt.

Even if shared_ptr (the name) goes away, I think the work which went
into it will stay: I think a that something with these semantics is a
reasonable choice for a default to be used. Whether it is realized using
a separate class or corresponding set of policies does not matter to me.

> I'd rather see a (concise) answer to the following questions instead:
> 
> 1a. Why is a smart pointer framework a good thing?
> 
> 1b. What are the design goals of the framework?
> 
> 1c. What user problems does this framework address?
> 
> 1d. How does the framework compare with other solutions to the user problems
> in 1c?

I decline from answering these ones: I'm interested mostly in a solution
to the interoperability problem which is, IMO, neither solved entirely
by 'shared_ptr' nor by 'smart_ptr'. I have the feeling that bring these
two things together plus some form of configuration possibilities for
the default pointer configuration may yield a satisfactory solution.
-- 
<mailto:dietmar_kuehl_at_[hidden]> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>