Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-26 11:21:36

On Mar 26, 2007, at 1:32 AM, Alexander Terekhov wrote:

> Howard Hinnant wrote:
> [...]
>> got a problem there. Indeed maybe even a bigger one: fclose is
>> allowed to throw! :-\
> That just means that you'd either have to deal with it (disable cancel
> at places where you don't want it to throw, or catch and self-re-
> cancel,
> or whatever) or just declare your code cancel unsafe (your clients
> will
> either disable cancel or simply won't cancel at all) and be done with
> it. Given that the later is the current state of affairs in today's
> (p)thread/C++ world, what the heck is the problem?

Perhaps just one of education.

I'm a cautious person and strive to fully consider the ramifications
of all the decisions we're making. It seems to me that the more
cancellation points we introduce, the more complicated the interface
becomes that we're introducing. We tentatively have cancellation
points to introduce in two categories:

1. New functions that haven't before appeared in the standard:

2. Existing functions that acquire this new functionality of
cancellation point:

Set 2 worries me more than set 1. If no one else sees any problems I
might be tempted to write it off as me being overly cautious (again).
But the last time I got LWG direction on this very subject, they were
much more agreeable to set 1 than set 2. That could change of
course. Perhaps we all just need a little more thought and
education. Or perhaps our caution is warranted.


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