Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-19 14:08:32

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> ----- Original Message -----
> From: "bill_kempf" <williamkempf_at_h...>
> > > either. Even if people behave the way you like and keep the
> > off the
> > > heap, there's no reason they can't touch it across threads.
This is
> > a simple
> > > case where it costs nothing to specify a more robust
> >
> > It's not very controversial. As I stated in another thread I just
> > want some discussion about whether such usage can just lead to
> > errors/abuses by the user and whether there's any valid reason for
> > using the technique in the first place. The specification isn't
> > robust if it leads to other errors/abuses with out adding any
> > benefit.
> Okay, maybe I should think about this. Turning off cancellation
just lets
> you call cancellation points without causing an exception. The only
reason I
> can think of to do this is to ensure an exception guarantee for an
> operation. The only reason I can think of to give the object a
> which is not synchronized with the heap would be so that
cancellation might
> be turned off or on in the middle of an operation. Okay, the
scenario goes
> like this: you have a long-running operation which must provide the
> guarantee. During the first part of the operation, it's okay to
throw an
> exception, because the original data is still recoverable. As soon
as the
> original data is first modified, the operation must run
successfully to
> completion, so you have to turn off cancellation. Cancellation
needs to be
> turned off in an inner loop and remain off until the operation
> Not hugely compelling, but plausible IMO.

Yes, plausible, but I don't see how this scenario requires a heap
based approach.

void operation()
  // initial stuff
     disable_cancellation protect;
     // loop
  // other stuff

Can you illustrate what you were thinking in code?

Bill Kempf

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