From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2006-03-29 03:37:19
David Abrahams wrote:
> I've developed some facilities that perhaps ought to be developed into
> full-fledged libraries or components of existing Boost libraries.
> This work centers around my long-standing threat to build a library
> that could create smart pointers safely, without ever exposing a raw
> pointer to the user. For example,
> #include <memory>
> #include <boost/shared_ptr.hpp>
> #include "new.hpp"
> struct foo
> foo(int&, char const*, std::auto_ptr<int> const&);
> std::auto_ptr<int> x(new_<int>(3));
> std::auto_ptr<foo> y(new_<foo>(*x, "hello, world", x));
> boost::shared_ptr<foo> z(new_<foo>(*x, (char const*)"hello, world", x));
> To solve this problem correctly, it was necessary to address "the
> forwarding problem"
> (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm). To
> that end, I developed some preprocessor macros that one can use to
> generate the necessary overload sets. Is there interest in adopting
> any of this code (enclosed), and if so, where should it go?
First, I'd like to say that I am very interested in this in a general
way, as I frequently end up writing forwarding sets (although usually
escape the forwarding problem).
I'm not intimate with the pp library, but if I read your code correctly
you have "solved the forwarding problem" by writing all the permutations
of const and non const for each forwarding set. Is that correct? If not
could you clarify for us non-PPers?
Personally I don't like the "new_" name. but that's purely subjective. I
think I'd prefer something more like, "atomic_new" (although that could
also be a bit misleading), or that at least has something more
descriptive to indicate what else is going on, other than just a bare
What about the array form?
Would it be worth going as far as to add static functions to the boost
smart pointer classes that do the same thing, and even hidding their raw
pointer constructors away so they can only be created using the safer
factory methods? Obviously that last step would break existing code, but
it would only break the largely unsafe uses.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk