On Tue, Nov 15, 2011 at 12:58 PM, Stewart, Robert <Robert.Stewart@sig.com> 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