Boost logo

Boost :

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-04-18 20:04:50


"Dietmar Kuehl" <dietmar_kuehl_at_[hidden]> wrote in message
news:20020418225307.61166.qmail_at_web12307.mail.yahoo.com...
Hi,

> now that you are looking into this message, I can admit that I'm not
> entirely opposed to policy-based smart pointers but there are
> considerable advantages of classes not using policies.

Specifically?

> 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.

Why similar? I donno maybe ResourceManager would be the bettr name and
decrease confusion. Here how I see the issue:

Almost any non-trivial program require some kind of resource management. It
could br memory, system resources like file handle, logical resources of the
program like shared objects and so on.
Programming expiprience allows us to identify some common patterns in
resource mangement. Using generative power of C++ we are trying to formalize
this patterns in form of reusable components. It may include usefull (proven
by time) interfaces, known tricks and pitfalls, efficient and safe
algorithms and so on. Real power of component is reflected in its
reusability in a different absolutly disconnecteed areas. SmartPtr<...>
should be able to manage any kind of resource with any desirable behavior.
SmartPtr template define a framework that uses user supplied policy that
define Resource/Behavior specifics. One SmartPtr<...> could be converted
into another SmartPtr<...> only if policy supports such conversion. The same
as with any two independent classes.

> For example, you cannot assign a
> smart pointer using an intrusive counter to a smart pointer using an
> external counter (well, if you are really careful this may be even
> workable but in general it is definitely not). That is, for the sake of
> interfaces you want to use just one style for an entity.

First of all even unified interface is already very valuable. It known to be
exception safe and efficient.
But other than that framework provide a lot of usaful features automatically
that you do not to implement. Compare, for example, size of any of your
custom smart ptr providing the same interface with the size of of Policies
defining the same functionality.

> <mailto:dietmar_kuehl_at_[hidden]> <http://www.dietmar-kuehl.de/>
> Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

Gennadiy.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk