Re: [boost] temp_ptr<> - preventing use as a member

Subject: Re: [boost] temp_ptr<> - preventing use as a member
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2011-11-17 01:37:22

On Tue, Nov 15, 2011 at 12:58 PM, Stewart, Robert
<Robert.Stewart_at_[hidden]> wrote:
> Gottlob Frege wrote:
>>
>> For example, a pointer passed into a function, that is only
>> valid for the lifetime of the function call.  A temp_ptr or
>> callstack_ptr or ... some better name.
>>
>> So this pointer would need a copy constructor so it can be
>> passed along into a function (I don't think requiring a ref to
>> the pointer would be good; I'd rather pass by value).
>
> If you relax this restriction,...
>
>> To prevent constructing one via the copy constructor that will
>> be kept around, I can define a custom new operator but keep it
>> private.
>
> ...you can avoid the need to do that...
>
>> The only thing, I think, that I can't prevent, is construction
>> of a new wrapper struct that has a temp_ptr as a member (which
>> is copy constructed in wrapper's constructor).  Can anyone
>> think of a way to prevent that?
>
> ...and prevent users from doing that, by making the type noncopyable.
>

Yep.  The tradeoff is
int func(temp_ptr<Foo> & foo)

not a big deal maybe, but it might be if my audience already is
uncomfortable with references vs pointers vs smart-ptrs (ie ex-java).
Throw a const or two in there and heads explode.  Maybe the whole idea
is a non-starter.  But I do wonder what code with all smart-ptrs would
look like.  Of course if I had to templatize all my, say, image
processing, because the pixel could be a temp_ptr<Pixel>,
some_other_ptr<Pixel>,... instead of just Pixel *, that might be
annoying...

Tony