Boost logo

Boost :

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk