Exception Specification Compromise
in [C++]
|
From: Martin B. on 9 Feb 2010 01:41 peter koch larsen wrote: > On 8 Feb., 14:36, "Martin B." <0xCDCDC...(a)gmx.at> wrote: >> DeMarcus wrote: > [snip] >>> Nevertheless, just because they're renowned C++ experts, that doesn't >>> stop me from proposing enhancements to their ideas. >>> So if the following holds: >>> * A no-throw function can, without functional harm, be declared throw() >>> since such function must throw nothing, compared to a throw( MyException >>> ) that can throw more than just MyException due to templates. >> If throw() is enforced during runtime - i.e. there is an implicit >> catch(...)+handler added to each such function - this can have >> performance implications depending on the platform. > > I assume that you mean "depending on the compiler", not the platform. > And this is true, but then complain to the compiler writers or choose > a compiler where this overhead is not present. Platform = HW + OS + compiler ? I used 'platform' because as far as I understood on Windows(x86) basically all compilers implement C++ exceptions on top of Win SEH exceptions and while that may not be totally accurate these handlers always incur a certain performance penalty. >>> If that holds, then I claim an optional feature in the compiler can, by >>> means of static checking during compile-time, help finding no-throw >>> functions that throws anyway. This optional feature would be no >>> disadvantage, but only an enhancement helping programmers writing >>> exception safe code. >>> Please give your comments on this. >> I fully agree that some mechanism to statically enforce/analyse the >> no-throw guarantee would be very welcome! > > The problem is one of technology. With the linking model we use now, > it is impossible. And changing the model does not really change > anything. > Determining if a function can throw is to the best of my knowledge not > possible, and if it is, surely it will be computationally to expensive > to be usable. > (....) The discussion was/seems to be moving in the direction that we don't want a 100% guarantee by the compiler that it won't throw, we just want some static checking. I understand it could be like with const. A const function doesn't guarantee *anything* (const-cast, mutable members), but still it's a useful tool! br, Martin -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 9 Feb 2010 01:44 DeMarcus wrote: >> Moreover, your suggestion is a bit like the objection to const. Once >> you start putting in const at the top level you have to fix everything >> you call to be const correct. It's one of those bullets that needs to >> be bitten. Considering the alternative is that your code will commit >> suicide at runtime if you get this wrong. And for some of us, that is >> not an option. As far as they affect us, exception specifications are >> not only useless, they are extremely dangerous. >> > > I don't know what's more dangerous; > > A) A function that throws even though it gives no-throw guarantee. > B) Programmers thinking they've created a no-throw function, when it > actually contains functions that can throw. > > What I mean is that exception specifications may be dangerous, yes, but > there is an exception; the no-throw exception specification throw(). > > > Maybe I should clarify that the standard does *not* need to be touched. > Not even the libraries have to be touched! > > The only thing I'm asking for is an optional feature in the compiler > that warns me if a function, declared throw(), contains any function not > declaring throw(). That's it! The rest I can do myself. Then just about every function will issue a warning because there are far too many library functions that cannot throw bot have no exception spec on their declaration. You would get so many warnings with no good way to fix them that you would soon get tired of it. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: ThosRTanner on 9 Feb 2010 01:49 > Determining if a function can throw is to the best of my knowledge not > possible, and if it is, surely it will be computationally to expensive > to be usable. > Just take a simple function like: > > std::vector<int> f() > { > std::vector<int> res(200000); > return res; > > } > > You can't determine if that function might throw unless you know what > new_handler is installed. You can easily tell if it might throw as opposed to won't throw. That function *might* throw because the constructor for std::vector<int> isn't declared throw(). A function won't throw if and only if the only functions it calls doesn't throw (and it doesn't throw itself of course). What you can never tell is if it it will throw but I don't think that's important. It is trivially easy to statically analyse whether or not a function might throw. You can even tell precisely what it might throw. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: DeMarcus on 9 Feb 2010 01:44 >> I fully agree that some mechanism to statically enforce/analyse the >> no-throw guarantee would be very welcome! > > The problem is one of technology. With the linking model we use now, > it is impossible. And changing the model does not really change > anything. > Determining if a function can throw is to the best of my knowledge not > possible, and if it is, surely it will be computationally to expensive > to be usable. > Just take a simple function like: > > std::vector<int> f() > { > std::vector<int> res(200000); > return res; > } > > You can't determine if that function might throw unless you know what > new_handler is installed. > > /Peter > Just to not diverge from the original thread I want to emphasize that the idea is to track no-throw functions only. Please note that the idea is also intended as an optional feature in the compiler. In other words, those who do not want to use it and/or have a reason to throw from no-throw functions like destructors, pop or cleanup functions in general, will not be affected if they choose not to use the particular compiler flag. The problems during linking, as you describe, will actually not be a problem. The main idea is simple; we just want to make sure no-throw functions are actually no-throw. Therefore the optional compiler feature would work like this. * If a function is declared throw() it is a no-throw function. If it is not declared throw() it may throw whatever, according to the compiler. * If a throw()-declared function contains any function that is not declared throw(), we get a warning. That's it! This small feature will be a tremendous help conforming to D. Abrahams no-throw guarantee. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Martin B. on 9 Feb 2010 01:41
DeMarcus wrote: >> BTW, as you say, you'd like an optional compiler feature. I don't >> think standard deals with such things - they define a language in >> "shall" and "shall not" terms. So a compiler could do that, as a >> quality of implementation enhancement, not the language (I could be >> wrong). Due to perf penalty of throw(), I bet you your proposal would >> end in some other mechanics, not "throw()". Perhaps some sort of a >> compiler-specific feature (e.g. through __declspec). >> > > Exactly! That's the beauty of it; the standard does *not* need to be > touched. Not even the libraries have to be touched! > > The only thing I'm asking for is an optional feature in the compiler > that warns me if a function, declared throw(), contains any function not > declaring throw(). That's it! The rest I can do myself. > I am very sure that some static checking tools out there already offer such a feature. (maybe via some annotation mechanism?) The problem with this approach is that this way the feature won't make it into any portable library and such will be of limited use. Has a nothrow keyword/function-annotation along the lines of const ever been proposed for the standard? cheers, Martin -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |