Boost logo

Boost :

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2000-05-30 19:27:34

--- In boost_at_[hidden], "Milutin Jovanovic" <miki_at_o...> wrote:
> ----- Original Message -----
> From: "Andrei Alexandrescu" <andrewalex_at_h...>
> > typedef SmartPtr
> > <
> > Widget*,
> > RefCounted,
> > CheckOnDereference
> > >
> > widget_ptr;
> Interesting. I saw a 'policy' class implemented somewhere else, and
it was
> full of defines. However, your approach seem to use inheritance.
That suggests
> you actually thought about this :-). I am intrigued. Is it possible
to see the
> code? It would be easier to discuss this with the work in front of

Yes, however it's going to take a while.

Policy classes do not use the preprocessor. Indeed, inheritance and
template parameters (often template templates) are the norm.

> But your classes are different. Changing the template arguments,
changes the
> programming model almost completely.

Not always. For instance, refcounted, reflinked, and gcollected
pointers sport mucht the same interface.

As I said, you can enable conversions between flavors as you see fit.

> Further more, with so many variations it is hard to remember what
is the
> policy of your current incarnation of the pointer. 'Have I made it
> 'CheckOnDereference' or not?'

On the contrary, it's very easy because you control fundamental
design decisions with a little piece of code (a number of typedefs).
In contrast, to figure out the policy used by a smart pointer
implementation from scratch, you don't have any chance but to examine
its source code. Yuck!

Moreover, to change the behavior you must do surgery on the smart
pointer code. With SmartPtr you change the type definition which is
compact and expressive.

Indeed I find using type definitions in conjunction with policy
classes and highly-configurable classes built with those policy
classes, a great tool for creating good, sound designs.

> Even worse, in an organization of 100
> programmers, every one might find a different flavour of the
pointer best.

Indeed, that's a risk. But I guess it more proves the power of
SmartPtr :o). Now without kidding, a powerful tool can be misused,
but I think with a little discipline the smart pointers in use in an
application can be collected in headers that are controlled by the
application designers.

> So
> when you start reading all that code together you will get lost
> quickly. My question. What is wrong with having several flavours as
> and sticking to them?


1. There's no way of combining them. Basically I have proved to
myself that there are few ways of combining behaviors at design time,
aside from using policy classes, and policy classes are the best way.

2. There's no way of configuring/tweaking them. Each app has some
specific needs, and I think anyone would acknowledge this. Just how
many times you said "Ah, I'd love to use BrainyPtr but I use COM and
BrainyPtr doesn't support COM"? With SmartPtr, adding COM support is
as easy as writing 15 lines of code.


Boost list run by bdawes at, gregod at, cpdaniel at, john at