David Abrahams wrote:
We dealt with this sort of philosophical issue a lot in the POSIX working group. We had two vocal and often diametrically opposed factions (which, in retrospect, was probably good; though it did make for some quite "interesting" meetings): the "academic" faction who wanted to design a clean interface that would make it not only "obvious" how to write a "correct" program but also difficult to write an "incorrect" program; and the realtime ("hard" realtime, as in NASA & Navy) types who frequently HAD to do those things, knew how to, and wanted clean and portable mechanisms.Gabriel Dos Reis <gdr@xxxxxxxxxxxxxxxxxxxxxxxx> writes:Such clear statement, from portability point of view, has different impact than an unspoken assumption.I think I heard what you were trying to say. Maybe I'm just blind to the answer, but while I think it's possible (though usually unconstructive) to formally label a particular programming construct evil, I don't think it's possible to formally bless a programming construct. Whether "catch-all without rethrow", or "while(1) loop without break", or "delete this", etc are going to be OK is dependent on program context, even if it is OK "in principle" in the POSIX environment. What can a formal specification say to bless a programming construct that could, depending on how it's used, lead to undefined or otherwise bad behavior?
Either extreme is philosophically defensible, perhaps; but neither is practical. Real code needs to do things sometimes that aren't 100% safe, and solutions will be developed. You're not really helping any by forcing those solutions to be non-standard and non-portable. On the other hand, some "unusually" unsafe things may really be too dangerous for a general purpose interface. There's no hard and fast rule that can help in drawing that line; it's a case by case judgement call by the committee and balloters. (With the inevitable result that people complain "why didn't you do this, when you did THAT, which is just as bad or even worse"... well, because the committee that day saw it differently, for whatever reason.)
This appears to be the same sort of situation. I'm not even going to pretend to have an answer; and in fact I'd argue that nobody does (or can) have "the" answer... if there even is one. ;-)
Getting back into context, we're adding cancellation. It has special semantics. That conflicts with wide and sanctioned usage of catch(...) without rethrow; and somehow we need to deal with this. We can say that all such code is now officially busted even though it was in standard libraries, and perhaps even recommended. We can somehow adjust the model so that it "works" anyway, as by Jason's "re-cancel on exception destruct"; recognizing that it becomes less convenient to catch when you really want to, and that we'll have extra unwinding (and loss of debugging information) when it happens.
We could require the language to perform some call stack analysis as part of deciding whether to deliver a cancel in the first place -- which goes along with my earlier "random speculation" that the C++ concept of 'cancel enabled' might be a dynamic property of the call stack rather than explicit API. I was thinking in terms of disabling cancel within a 'throw()' scope... but there might be other conditions. For example, we could disable inside either 'throw()' or any try with a catch(...) that doesn't rethrow... unless there's an INNER scope that allows throwing cancel AND with an explicit catch(cancel). So a nothrow destructor (regardless of whether all destructors were implicitly nothrow or not) could allow "local" cancellation by nesting a try{} catch(cancel) {}.
(Sounds too complicated; but it's something to think about. ;-) ) -- /--------------------[ David.Butenhof@xxxxxx ]--------------------\ | Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect | | My book: http://www.awl.com/cseng/titles/0-201-63392-2/ | \----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/