Re: Implementation of shared_ptr
On Jan 29, 9:41 pm, Marcel M=FCller <news.5.ma...@spamgourmet.com>
wrote:
Juha Nieminen wrote:
Your ref_count class lacks a proper copy constructor and
assignment operator, which means that it will fail
spectacularly if objects inherited from it are
copied/assigned around (if the reference count in the source
and target are different).
You are right. The objects that I protect by a class like this
have an application wide primary key. So they are non-copyable
anyway, because if I copy them the key would no longer be
unique.
This is an extremely typical mistake with intrusive reference
counting. It's trivial to fix, though.
class ref_count
{ friend void intrusive_ptr_add_ref(ref_count*);
friend void intrusive_ptr_release(ref_count*);
private:
unsigned count;
protected:
ref_count() : count(0) {}
ref_count(const ref_count&) : count(0) {}
virtual ~ref_count() {}
ref_count& operator=(const ref_count&) { return *this; }
public:
bool ref_is_managed() { return ref_count != 0; }
bool ref_is_unique() { return ref_count == 1; }
// Only a return value of true is thread-safe.
};
In general, if you're allocating objects dynamically, it's
because they have identity, and aren't copiable. (There are
doubtlessly exceptions, but they aren't that common.) So just
ban copy and assignment. The client code can always reactivate
it for his classes, if it makes sense.
But maybe it makes more sense to derive from
boost::non_copyable instead, because copying reference counted
objects is likely to be not what you intended. A derived class
may still implement copy and assignment semantics explicitly.
Exactly.
But intrusive reference counting is still a extremely
lightweight method for moderate requirements. The runtime
overhead is quite small.
That's one reason to use intrusive reference counting, but it's
not the only one, nor even the most important one.
Non-intrusive reference counting is extremely brittle; with
boost::shared_ptr, for example, you need to take extrodinary
precautions to ensure that you don't end up with two distinct
counters. (The Boost documentation suggests making all of the
pointers to the object boost::shared_ptr. Which is fine, but
the compilers I use don't collaborate---this isn't a
boost::shared_ptr.)
That's for the cases where reference counting is appropriate, of
course. which aren't all that frequent to begin with.
OK the interlocked access to the reference counter does not
scale that good on x86/x64 SMP machines, but this is more
related to x86/x64 than to the method.
The interlocked access is necessary regardless of the strategy.
On the other hand, I find that when an object is being passed
between threads, auto_ptr is more appropriate: once the second
thread has access, you don't want to allow access from the first
thread.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34