Re: Hello boosters

From: Miki Jovanovic (miki_at_[hidden])
Date: 2000-05-30 16:51:17

Hi Andrei,

I will tackle two points from your post, and I hope other boosters 
will jump in regarding topics they feel comfortable in.

Firstly I want to remark that I like the idea of bringing as much 
general reusable code into boost as possible. As long as the two sets 
of boost classes are independent (can be used without the other).

That said, I do have comments on:

> * SmartPtr - a smart pointer based on a carefully-chosen set of 
> policy classes, that is extremely flexible and very behavior-rich. 
> There are about 160 possible behaviors implemented with a small 
> codebase, and in particular you can imitate auto_ptr, shared_ptr
and 
> linked_ptr. SmartPtr even supports non-pointer (handle-based) 
> representations. Because SmartPtr is actually nothing but a 
syntactic 
> shell that integrates six policies, I hope that you never have to 
> develop a smart pointer from scratch; instead, you would write new 
> policies for SmartPtr.

I will be hard pressed to support this kind of generalization. I 
strongly believe that a class should do one thing and one thing only 
(KISS). You talk about 160 different behaviours. If I want a 
shared_ptr, I do not want to have even to know of other 159 possible 
behaviours. I have trouble explaining the smart pointer concept to 
some programmers, I can only imagine the headache of making them use
a class that has 160 variations in behavior. 

And this even does not touch the topic of standardising object
access. Imagine if std containers had this configurability. You would 
not be able to write a reusable piece of code, because depending on 
your 'policies' container would behave differently.

Concept of a handle_ptr (or whatever you call it) is a very 
interesting one. This might find its way to boost quite easily.

> * Threading amenities - this is a tough subject, but I couldn't 
> ignore providing some support.

There are two points with this. First, Boost accepts only standard
C++ code that will compile on any platform with a C++ compiler. So 
this group might be knocked out on technicality. But...

I am VERY interested in this topic. I myself am working on a set of 
threading/synchronization classes that are simple enough to be easily 
ported. I would be very interested to see how have you abstracted the 
threading primitives. Have you compromised the functionality to the 
lowest denominator, or did you opt for more complex API, and 
implemented the missing features on platforms that do not support the 
functionality.

If Boost is not a good place for these threading amenities, I would 
like to take this off-group.

Cheers,

Miki.