Re: Hello boosters

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

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 
pretty
> quickly. My question. What is wrong with having several flavours as 
standard,
> and sticking to them?

Because:

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.

Andrei