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

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

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

> David Abrahams wrote:
>> Phil Nash <phil.nash.lists_at_[hidden]> writes:
>
>>> 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 (?)
>
> Very true. For me, at least, that does kinda remove the need.
>
>>> Would it be worth going as far as to add static functions to the
>>> boost smart pointer classes that do the same thing, 
>> 
>> Yes.

Oh, but wait: this could introduce a lot of code duplication.  It
would probably be better to make the new free function a friend if you
want to do something like that.

>>> 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 :(
>
> I see that Larry has been talking about much the same thing.
> It wouldn't be the first time that boost has changed an interface to 
> make it safer, even though it breaks older code. I suppose the 
> difference is that the smart pointers are probably the most used classes 
>   of the whole of boost!
>
> It could be done in stages, with the raw pointer and maybe auto_ptr 
> constructors retained but deprecated, and later removed. Not sure if 
> that helps much.
>
> In any case, it would need to be put to some vote once some concrete 
> proposals are in place. I'd still urge you not to rule it out at this stage.

It's not up to me; I don't maintain the smart pointer library.

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