Phil Nash <phil.nash.lists@gmail.com> 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