Boost logo

Boost :

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
> linked_ptr. SmartPtr even supports non-pointer (handle-based)
> representations. Because SmartPtr is actually nothing but a
> 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

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



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