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:
>> 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,
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk