Re: [boost] Smart Pointer new/Forwarding Problem Solved (by Force)

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 
trailing _.

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.

Best regards,

[)o
IhIL..