Boost logo

Boost :

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2000-05-30 22:58:48

--- In boost_at_[hidden], "Paul Baxter" <paul_baxter_at_i...> wrote:

Sorry I skipped this message.

> My main concerns would be the run-time cost of having this
flexibility over
> hand-crafted solutions and whether a suitable common interface is
> for potentially such a large variety of smart pointers.

I answered to the efficiency issue in another post. In a nutshell, in
the presence of reasonable optimizations, efficiency is good.

I am deeply convinced that the "evil multiplicity" of the real world
will someday bend SmartPtr on its knees, but what I am trying to do
with it is covering a very large percentage of behaviors and possible
future variations, so that only very rarely you'll have to restart
from scratch. But sometimes you'll have, I have no doubt about it. I
just want not to restart just for the sake of a minor thing like a
different convention in naming the Refer/Release functions.

> 1) Do/will your submissions meet the licensing terms for inclusion
> boost? i.e. free for commercial/non-commercial, modifiable etc.

I think so, I'll consult my publisher. The code itself is very likely
going to be free, it's documentation I'm concerned about as the book
is the documentation.

> 2) I'm sure the code has a style for inclusion in your book (which
I eagerly
> await) but which I suspect may not be quite the same as boost.
> Would you be willing to modify the code for inclusion (in exchange
for the
> additional constructive criticism :) ) or is that something you'd
like to
> see someone else do?

This I don't know. I use Herb's coding standards (Capitalized
class/function names, lowerCaseThenCapitalized variable names,
underscore appended_ to member variables etc.). Changing to the
boost/std style would be an effort. Likely it's not going to be a
major hitch.

Hmm, I wonder why all the interest gravitates around smart
pointers... :o)


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