| Ian Collins <ian-news@hotmail.com>: Sep 08 12:40PM +1200 On 07/09/2019 01:51, Scott Lurndal wrote: >> actually throwing an exception. > It's the unwinding support that adds overhead. Regardless of whether > the exception is ever thrown in any particular codepath. Surely the unwinding has to happen on function return whether you are using exceptions or not? > When simulating an instruction, if an exception is detected (illegal > instruction, illegal operand, instruction timeout, etc), it will > longjmp back to the main loop. Doing so will bypass any object destructors, so you would have been restricted to the C with classes subset. Which implies there would have been nothing to unwind had you used exceptions. Using longjmp with anything beyond the C with classes subset is a bad idea in C++. > even given the infrequency of longjmp calls/throw (exceptions in production > code are rare; mainly when the stack limit is reached and more stack needs > to be allocated by the OS to the application). How long ago was this by the way? We had to disable exceptions in an embedded project in the early 2000s due to performance issues that aren't there in modern compilers. Exception performance has improved significantly in recent years. -- Ian. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 08 08:29PM +0200 > You like authorities, right? E.g. you professors? > Here is an answer from pretty high authority. > https://google.github.io/styleguide/cppguide.html#Exceptions That are not academic statements but rather a matter of taste. "When you add a throw statement to an existing function, you must examine all of its transitive callers. Either they must make at least the basic exception safety guarantee, or they must never catch the exception and be happy with the program terminating as a result. For instance, if f() calls g() calls h(), and h throws an exception that f catches, g has to be careful or it may not clean up properly.": Simply either derive all exceptions from a single class (I derive my exceptions from std::exception) and if you glue a secondary library catch the base-class of that exception-hierarchy also in a central point. But catching the exceptions more specifically at a more appropropriate point and more specifically isn't hard if you have a poper documentation. "More generally, exceptions make the control flow of programs difficult to evaluate by looking at code: functions may return in places you don't expect. This causes maintainability and debugging difficulties. You can minimize this cost via some rules on how and where exceptions can be used, but at the cost of more that a developer needs to know and understand." That's´not a con, that's a pro in most cases. F.e. you usually don't have to know where an operation failed; you simply have to know that it failed. "Exception safety requires both RAII and different coding practices. Lots of supporting machinery is needed to make writing correct exception-safe code easy. Further, to avoid requiring readers to understand the entire call graph, exception-safe code must isolate logic that writes to persistent state into a "commit" phase. This will have both benefits and costs (perhaps where you're forced to obfuscate code to isolate the commit). Allowing exceptions would force us to always pay those costs even when they're not worth it." You have to write wrapper-classes to maintain RAIIness. And in some cases you have to do this for a single use; that's while i long for something like finally in C++. I helped myself by having a class called invoke_on_destruct which has a template-parameter of another class that which is usually a lamda hose operator () is called when the destructor of this class is called. This looks like this: auto waitForThread = [&threadLock, pPT]() { threadLock.lock(); while( pPT->m_rsp == pool_thread::RSP_NONE ) pPT->m_sigResponse.wait( threadLock ); }; invoke_on_destruct<decltype(waitForThread)> autoWaitForThread( waitForThread ); But of course a finally would look better because it would be executed at the point where the code is placed. "Turning on exceptions adds data to each binary produced, increasing compile time (probably slightly) and possibly increasing address space pressure." Mostly doesn't matter. "The availability of exceptions may encourage developers to throw them when they are not appropriate or recover from them when it's not safe to do so. For example, invalid user input should not cause exceptions to be thrown. We would need to make the style guide even longer to document these restrictions!" You have to be a skilled developer for C++ anyay. A lot of language -features could be misused. > Just one of many possible answers and not necessarily the one I > agree with. "On their face, the benefits of using exceptions outweigh the costs, especially in new projects" > sentiments coming from academic propaganda rather than from deep > development experience. But at least a bottom line (headline, it > this case) is correct. You don't argue from experience but from tase. |
| Dhu on Gate <campbell@neotext.ca>: Sep 08 06:06AM On Thu, 08 Aug 2019 12:15:48 -0500, peteolcott wrote: > on the basis that its satisfaction derives a contradiction. > Proof that Wittgenstein is correct about Gödel > https://www.researchgate.net/publication/333907915_Proof_that_Wittgenstein_is_correct_about_Godel Since this is unreadable by peons, I can only speculate, but provably unprovable sounds like a useless tautology. Dhu -- Je suis Canadien. Ce n'est pas Francais ou Anglaise. C'est une esp`ece de sauvage: ne obliviscaris, vix ea nostra voco;-) http://babayaga.neotext.ca/PublicKeys/Duncan_Patton_a_Campbell_pubkey.txt |
| Ian Collins <ian-news@hotmail.com>: Sep 08 12:29PM +1200 On 08/09/2019 07:28, Bo Persson wrote: > http://eel.is/c++draft/temp.arg.explicit#4 > Not obvious at all, if you happened to skip over the last part of this > sentence. :-) Thanks for filling in the gaps and the link! I glad I'm not a compiler writer... gcc-9 gets it right, gcc-8 gets it wrong. -- Ian. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment