From: DKl_at_[hidden]
Date: 2002-04-19 10:27:18
Andrei Alexandrescu wrote:
> I'm not sure what you are suggesting. At the end of the day, they
> _will_ be different types, be it through specialization or whatever.
What do you mean with 'shared_ptr<T>' and 'shared_ptr<T>' will be
different type? 'shared_ptr<T1>' and 'shared_ptr<T2>' may use
different policies and they are different types, of course. Whether
'shared_ptr<T>' uses an intrusive or an external counter, for example,
is invisible and up to the configuration.
My point is that there should be one smart pointer type to be used for
passing "pointers" to 'T' around: This type appears in interfaces. It's
exact definition, ie. the management policies used, may vary between
types (eg. be intrusive for some types, be external for other types).
However, using a 'shared_ptr<T>' for some types and an
'instrusive_ptr<T>' for other types is a bad idea: For example, generic
interfaces unaware of special type properties are likely to use a
'shared_ptr<T>' while interfaces with specific knowledge are likely to
use 'instrusive_ptr<T>'. Unfortunately, these two types are
incompatible and objects produced by one component cannot be used with
functions of the other component. This is a bad idea.
My suggestion was an approach to produce the desired type safety Peter
Dimov requested: In some situations, it may be reasonable to ascertain
that certain internal properties are met. However, to the outside the
same type should still be used. This is what the function template
'make_intrusive()' achieves: If you care that the generic name for the
smart pointer refers to an intrusive implementation for that particular
type, you just use 'make_intrusive()' rather than 'shared_ptr<T>()'. If
you don't care (as is often the case eg. in template code) you would
just use 'shared_ptr<T>()' (or 'make_ptr()' to avoid explicitly
specifying the type).
-- <mailto:dietmar_kuehl_at_[hidden]> <http://www.dietmar-kuehl.de/> Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>