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

Subject: Re: [boost] temp_ptr<> - preventing use as a member
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-11-28 18:17:36

on Thu Nov 17 2011, Gottlob Frege <gottlobfrege-AT-gmail.com> wrote:

> On Sun, Nov 13, 2011 at 8:52 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>>
>
>> on Sun Nov 13 2011, Gottlob Frege <gottlobfrege-AT-gmail.com> wrote:
>>
>>> 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?
>>
>> I'm pretty sure there's no way to do that.
>
> Thinking about it more, I realize that *in debug* I could probably
> write some strange code that detects whether the copies are going into
> objects on the stack or not.  Not very portable to say the least.

Oh, sure, in non-portable code at runtime, you can do it.

>>> I think anyone that goes out of their way to make a wrapper struct
>>> gets what they deserve, so I don't really *need* to prevent all bad
>>> uses. Â But I can aslo imagine someone just using it improperly inside
>>> their class due to misunderstanding or whatever.
>>>
>>> And thoughts on the goal of specific smart pointers for all occasions?
>>
>> Sounds interesting; I'd like to know how it turns out for you in
>> practice.
>
> I wish I had 6 months to try it out and now had answers.  People are
> requesting guidance *now*.  We'll see...

FWIW, my instinct is that if you need that many pointers (or _ptrs) and
you're worried that they're too liberal, then you should probably
re-think your approach.  Most code doesn't need to expose reference
semantics; it can often be hidden behind well-tested and
tightly-encapsulated library interfaces.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com