Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at