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