From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-11-17 12:26:41
From: "Mattias Flodin" <flodin_at_[hidden]>
> On Sat, 17 Nov 2001, Peter Dimov wrote:
> > In order to make shared_ptr thread safe (w.r.t. reference counting) we
> > an atomic_counter type, with the following operations defined:
> > atomic_counter a(n); // n is the initial value, convertible to 'long'
> > ++a; // atomic increment, returns the new value (by value, type 'long')
> > --a; // atomic decrement, returns the new value (by value, type 'long')
As Carl Daniel correctly observed these need not return the new value, only
something that is sign-compatible with it.
> > a; // convertible to long, atomic read (to support use_count() and
> Pretty nice. Two questions: Firstly is there a rationale for not
> allowing / implementing postfix increment and decrement?
It's simply not used. There is no reason to define more operations on
atomic_counter - it's supposed to be the minimal thing that does the job.
> Secondly, I'm
> just curious, why are you adding zero to _MSC_VER?
To suppress warnings when _MSC_VER is not defined (I saw this trick being
used in Boost.Config.)
> Since the required range of a counter may vary, perhaps it is not
> unreasonable to parameterize this class with respect to the counter type.
No, the class is not "parametric" WRT the underlying type since for some
types the platform might not support efficient atomic updates. The actual
range of an atomic_counter is vaguely defined as "something usable for a
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk