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: thread::join this_thread::sleep etc. 2. Existing functions that acquire this new functionality of cancellation point: fclose fflush fgetc fopen fprintf etc. 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. -Howard