Re: [boost] Re: Re: move_ptr

From: Daniel Wallin (dalwan01_at_[hidden])
Date: 2004-01-21 11:00:40

Jonathan Turkanis wrote:
> "Daniel Wallin" <dalwan01_at_[hidden]> wrote in message
> news:400E9464.1040608_at_student.umu.se...
> 
>>Jonathan Turkanis wrote:
> 
> 
>>Also, in general, it is far easier to start with less and add more
> 
> later
> 
>>than to throw everything in from the start and remove later.
>>
> 
> 
> I don't think so. I've already written the policy based version, with
> two policies -- no_storage and auto_storage; I'm just working on one
> or two more. It should be quite simple to get rid of it later.

That's not the point. Removing things will break client code, adding
things won't. Nobody is arguing that this is hard to implement, and even
if it was, that shouldn't dictate design choices.

>>If adding a template parameter is absolutely essential, we'll end up
>>with a half-baked smart_ptr<> and we could just as well spell
>>move_ptr<>:
>>
>>    smart_ptr<T, move_semantics, array_storage>
>>    smart_ptr<T, move_semantics, scalar_storage>
>>
> 
> I liked Howard's ideas about handling smart pointers to arrays, and
> think it should be straigforward to implement. (I haven't done it yet
> because I don't want to obscure the issue of deletion policy.) I don't
> think adding treament for arrays will require an additional template
> parameter, so we shouldn't end up with a long list of policies.

I like handling array deletion as well, but that doesn't imply that we
need deletion policies.

-- 
Daniel Wallin