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

From: David Abrahams (dave_at_[hidden])
Date: 2006-03-29 08:16:48

Phil Nash <phil.nash.lists_at_[hidden]> writes:

> 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?

That is correct.

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

Come up with a better name and I'll consider it.

> What about the array form?

IMO it's not a very important use case, but if we have to support it,
it would have accept the T[N] form and return shared_array:

   new_<int[50]>();

interestingly, I think there's only a viable zero-argument form for
this ctor, so forwarding may not be of interest (?)

> Would it be worth going as far as to add static functions to the
> boost smart pointer classes that do the same thing, 

Yes.

> and even hidding their raw pointer constructors away so they can
> only be created using the safer factory methods?

Probably not.

> Obviously that last step would break existing code, but it would
> only break the largely unsafe uses.

Except for the few safe ones :(

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com