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
> 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
> 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
> additional constructive criticism :) ) or is that something you'd
> 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
Hmm, I wonder why all the interest gravitates around smart
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk