From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-04-20 06:22:10
From: "Gennadiy Rozental" <rogeeff_at_[hidden]>
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> > From: "Dietmar Kuehl" <dietmar_kuehl_at_[hidden]>
> > > OK, before you start thinking I have gone entirely stupid (which you
> > > are, of course, free to think anyway), I want to clarify a little bit:
> > > The problem with policy-based designs is that similar entities with a
> > > similar intention become incompatible.
> > You are right. In particular, the problem is that when library A uses
> > smart_ptr<T, X> and library B uses smart_ptr<T, Y>, the authors of X and
> > must know about each other in order to provide a conversion.
> > shared_ptr<T>'s custom deallocator support deliberately doesn't use
> > template parameter to avoid this possibility.
> You keep repeating this argument, but I still do not see why is it
As all problems, it's only important if you've encountered it, and
The problem is more psychological than technical. Given std::shared_ptr<T>,
library designers will have a common ground and library interoperability
will be almost a side effect. Given std::smart_ptr<T, SP, OP, KP,
WhateverP>, library designers - by default - will choose different smart
pointer types for their interfaces, since it's well known that personal
preferences vary wildly. Now, to achieve interoperability, library authors
must agree on a common ground; or, to put in a different way, they need to
establish a de-facto standard.
The problem is not policy-specific. It's about degrees of freedom.
> 1. Could you provide reallife example shouing that this is an issue.
No, if you have policy-based designs in mind, not just different types.
Policy-based designs are still rare.
> 2. Is this only smart_ptr related? What about iterator_adaptors for
No, it applies to all parameterized types. More degrees of freedom, more
power, more responsibility.
> 3. Could you sketch you solution with current smart_ptr?
Solution to what problem?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk