Boost logo

Boost :

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 <> wrote:

> On Sun, Nov 13, 2011 at 8:52 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>> on Sun Nov 13 2011, Gottlob Frege <> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at