Re: Hello boosters

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 
possible
> 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 
into
> 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)

Andrei