Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-18 21:32:27

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> ----- Original Message -----
> From: "bill_kempf" <williamkempf_at_h...>
> > Hmmm... interesting thought. Means ref-counting, but as long as
> > these instances aren't shared between threads (and they shouldn't
> > this isn't going to effect the speed much at all. I can't
> > the scenario in which this would actually be useful, but I'm not
> > adverse to considering it. Some further discussion about this
> > be very welcome.
> Even if we can't envision a realistic usage scenario that places
them in
> dynamic memory, just consider the consequences if they are, and you
keep the
> semantics as written. Cancellation might be turned off permanently,
> though all the disablers are destroyed.

I hesitate to say this because I don't want to argue the point too
much since I mostly agree with the idea in general. However,
allocating it on the stack will be no more disastrous (probably less
so) then sharing it across threads. In other words I'd envisioned
the usage to be like that of the scoped_lock classes, meant to be
used on the stack and never shared between threads. The user can
violate this, but if they do it's a simple programming error. We
can't prevent them from shooting themselves in the foot. So the fear
that allocating them on the heap could cause cancellation to be
turned off permanently isn't a very strong argument for me. The fact
that heap based usage where as long as one exists then cancellation
is disabled is a stronger argument. I just wish I could envision a
usage where this would really be used.

Bill Kempf

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