From: David Abrahams (dave_at_[hidden])
Date: 2002-09-17 11:29:58
From: "Peter Dimov" <pdimov_at_[hidden]>
> From: "David Abrahams" <dave_at_[hidden]>
> > > > Why? What's special about being within a member function?
> > >
> > > Nothing in particular; this is simply the intent of shared_from_this,
> > > solves the specific "how do I obtain a shared_ptr from this" problem.
> > I would prefer "shared_from_raw", since it can just as legitimately be
> > outside a member function.
> shared_from_raw was one of the options. But it implies that raw-to-shared
> conversions are universally needed, something that I don't agree with. I
> have encountered the "shared_ptr from this" problem several times, and I
> forced to switch to a custom intrusive-counted pointer because of it; the
> problem has also been reported by James Kanze as a major reason to avoid
> boost::shared_ptr. I don't want to acknowledge the general case - "how do
> get a shared_ptr from an arbitrary raw pointer" - as a problem.
It's no less-legitimate than "how do I get a shared pointer from an
*arbitrary* this pointer".
> dangling_weak_reference is good. Noted for the release after... but you
> > > I think that the scenario you are describing isn't allowed, as
> > must
> > > share memory.
> > I don't understand your remark. The scenario I describe is caused by
> > precisely this fact. It seems to me that either thread startup takes no
> > parameters at all, or at *some* point the starter and startee will have
> > be holding references to the same shared_ptr.
> True (this applies to any C++ class and not just shared_ptr, I think;
> fundamental types seem affected). But the implementation should guard
> accesses with an internal mutex. See for example thread_param and
> thread_proxy in libs/thread/src/thread.cpp.
I see. I think.
David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com