| Bonita Montero <Bonita.Montero@gmail.com>: Sep 01 05:16AM +0200 > For some software, exceptions are ruled out as a technique because they > take too long, and in particular, their timing is very hard to predict. Another time: the performance of resource- or I/O-collapse-handling is never relevant. >> every call-level is a lot of work. > Again, you don't see the big picture and think that your ideas cover > everything. I see "the big picture" - you are not. > you have lots of call levels between identifying a problem and dealing > with it. And using exceptions is a /huge/ amount of work for some kinds > of analysis of code and possible code flows. Wrong; you catch them in a central point and that's all. >> anyway. > You do understand that people use exceptions for a variety of reasons, > don't you? They are used for resource- or I/O-collapse - and nothing more. > how slowly we act as the program is falling apart" then why have an > exception system in the first place? Just call "abort()" and be done > with it. You don't have any reliability any more at this point because the operation simply failed. The timing isn't relevant any more a this point. |
| "Öö Tiib" <ootiib@hot.ee>: Sep 01 03:21AM -0700 On Sunday, 1 September 2019 06:16:45 UTC+3, Bonita Montero wrote: > > take too long, and in particular, their timing is very hard to predict. > Another time: the performance of resource- or I/O-collapse-handling > is never relevant. Where it is written that exceptions are only for handling resource or I/O collapse? Exceptions are typically thrown in situation when a function (such as operator or constructor) can't fulfill its post-conditions. Running out of resources or failures of I/O are just easy examples why it may happen. > > Again, you don't see the big picture and think that your ideas cover > > everything. > I see "the big picture" - you are not. Yet the current exceptions can't be used for some hard-real time projects exactly because of bad performance on failure case. See http://stroustrup.com/JSF-AV-rules.pdf Basically they have to extend their post-conditions of all functions that may fail with failure state and to check it. And you don't seem to understand why it is so. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 01 12:25PM +0200 > Running out of resources or failures of I/O are just easy examples > why it may happen. Tell me more where exceptions might be used! |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 01 12:35PM +0200 >> Running out of resources or failures of I/O >> are just easy examples why it may happen. > Tell me more where exceptions might be used! Or better: mention a class-library that uses exceptions for something different than what I told! |
| "Öö Tiib" <ootiib@hot.ee>: Sep 01 04:13AM -0700 On Sunday, 1 September 2019 13:35:17 UTC+3, Bonita Montero wrote: > > Tell me more where exceptions might be used! > Or better: mention a class-library that uses exceptions > for something different than what I told! Huh? C++ standard library and <https://www.boost.org/> contain piles of throws for numerous other reasons. Rather elementary things like Boost.Lexical_Cast may fail and throw. |
| Ian Collins <ian-news@hotmail.com>: Sep 01 11:18PM +1200 On 01/09/2019 23:13, Öö Tiib wrote: > Huh? C++ standard library and <https://www.boost.org/> contain piles > of throws for numerous other reasons. Rather elementary things > like Boost.Lexical_Cast may fail and throw. Even more basic, std::vector::at(). -- Ian. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 01 02:04PM +0200 >> piles of throws for numerous other reasons. Rather elementary >> things like Boost.Lexical_Cast may fail and throw. > Even more basic, std::vector::at(). OK, you're right. But the first exception isn't thrown in a per -formance-relevant case. .at is, but this might make it useless in many cases as eceptions are slow. I just measured the performance of trowing an int and catching an int & with VC++ and it is about 3 million clock-cycles: // main translation-unit #include <windows.h> #include <iostream> #include <intrin.h> void Thrower(); using namespace std; int main() { // to get always the same TSC SetThreadAffinityMask( GetCurrentThread(), 1 ); typedef long long LL; unsigned const REP = 1'000; LL start, end; start = (LL)__rdtsc(); for( unsigned i = REP; i; --i ) try { Thrower(); } catch( int & ) { } end = (LL)__rdtsc(); cout << (double)(end - start) / REP << endl; } // throwing translation-unit void Thrower() { throw int( 123 ); } Maybe anyone could adapt this for other compilrs / platforms; I'm curious about the results. Compile it without interprocedural optimizations to prevent the compiler from optimizing away the whole throw-try-catch-issue. |
| Paavo Helde <myfirstname@osa.pri.ee>: Sep 01 03:49PM +0300 On 1.09.2019 1:06, David Brown wrote: > On 31/08/2019 16:17, Paavo Helde wrote: >> On 31.08.2019 3:05, Anton Shepelev wrote: > RAII to protect resources is not remotely dependent on exceptions : Sure, but exceptions are dependent on RAII. Without RAII it is not really feasible to use exceptions, as demonstrated by ugly, tedious and error-prone 'finally' clauses in C# and elsewhere. > whatever code size is appropriate) that reads data from a file and > crunches it. Make a function that reads data from the file. Make > another function that crunches data. There is no difference, the function reading the data still has no clue how to "handle" an error. > crunch it, returning the correct result or some sort of error indicator > when a problem is found. That error indicator could be an error code, a > std::optional nullopt, a tuple field in the result - or a thrown exception. Right, the function cannot handle the error by itself and reports it back to the caller. Ergo, the error handling code resides somewhere else than in this low-level function, ruining the dubious "transparency" ideal advocated by GP. The distance between error detection and handling is different in different kind of software. It might be that the error is handled 1 - 2 call stack frames up, making the error code approach pretty straightforward. In the code I usually work with this distance is typically 10 - 20 call stack frames, making the exceptions approach much more convenient. |
| David Brown <david.brown@hesbynett.no>: Sep 01 04:03PM +0200 On 01/09/2019 05:16, Bonita Montero wrote: >> predict. > Another time: the performance of resource- or I/O-collapse-handling > is never relevant. All I can say is that I am glad I don't have to rely on your software. It's one thing to be ignorant - but your blind, stubborn, wilful and insistent ignorance is fortunately exceptional. |
| David Brown <david.brown@hesbynett.no>: Sep 01 04:12PM +0200 On 01/09/2019 14:49, Paavo Helde wrote: > Sure, but exceptions are dependent on RAII. Without RAII it is not > really feasible to use exceptions, as demonstrated by ugly, tedious and > error-prone 'finally' clauses in C# and elsewhere. Agreed. You need RAII - or, more specifically, deterministic destructors - for exceptions to work well. My point is merely that you get the RAII advantages no matter how you handle errors or unusual situations, whether it be C++ exceptions, future "zero overhead" or "checked" exceptions, error return codes, or anything else. >> another function that crunches data. > There is no difference, the function reading the data still has no clue > how to "handle" an error. That can be true - but a key difference is that the reading function knows there can be errors. It might not handle those errors, but it does not ignore the possibility of their existence. > straightforward. In the code I usually work with this distance is > typically 10 - 20 call stack frames, making the exceptions approach much > more convenient. Sure, if exceptions are right for your code, use exceptions. I am not suggesting that exceptions are bad - merely that they are not always the best choice. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 01 06:22PM +0200 > All I can say is that I am glad I don't have to rely on your software. > It's one thing to be ignorant - but your blind, stubborn, wilful and > insistent ignorance is fortunately exceptional. You're a mega-idiot as you don't understand that error-handling isn't performance-crucial. |
| Richard Damon <Richard@Damon-Family.org>: Sep 01 03:23PM -0400 On 9/1/19 12:22 PM, Bonita Montero wrote: >> insistent ignorance is fortunately exceptional. > You're a mega-idiot as you don't understand that error-handling isn't > performance-crucial. If the result of not handling the error in time is someone gets killed, maybe it is. 'Error' Handling often can be a critical part of the system (and sometimes it isn't). The issue is that 'Generic' answers aren't always right, sometimes certain things are important, and sometimes they are not. In many cases, the cost of the exception path isn't that important, but sometimes real WORSE case performance is, sometimes the error path may have relaxed requirements, but sometimes it still has definite requirements. Exceptions can't be true Zero overhead, they may be able to push the overhead into things that aren't important most of the time, but might be important in some cases. The shifting of exception cost to static data/code space and away from execution time is good in many cases, but it does raise the cost of the exception path, sometimes significantly (and perhaps too high of a cost). Error Return Values sometimes have the advantage that the cost is up front and more directly controllable, the cost of exceptions is very much fixed by the implementation, and not as controllable. If your usage matches the cases that the implementation optimized for, it can be good, if not, it may not be so good. |
| David Brown <david.brown@hesbynett.no>: Sep 01 10:39PM +0200 On 01/09/2019 21:23, Richard Damon wrote: >> performance-crucial. > If the result of not handling the error in time is someone gets killed, > maybe it is. And that is the point. (Though it is much broader than live-critical code.) Bonita seems to think the world runs on programs on desktops, where it is fine to have error messages popping up saying "There was an error saving the file to disk. Press OK to continue". For some programs, that kind of error handling is fine. But for some programs, it is /not/ fine at all, and /timely/ handling of errors is critical for your car to work, your telephone to work, your insulin pump to work, your cable TV service to work. > 'Error' Handling often can be a critical part of the system (and > sometimes it isn't). Yes. > The issue is that 'Generic' answers aren't always right, sometimes > certain things are important, and sometimes they are not. I'd go further, and say that generic answers are wrong so often that they are simply "wrong". > sometimes real WORSE case performance is, sometimes the error path may > have relaxed requirements, but sometimes it still has definite > requirements. Exactly. A key concept here is "real time system". That is used to mean things happen within particular times - known, pre-determined times. Deadlines are hard - you don't get to miss them. It doesn't matter if a system is fast or slow, it matters that it is predictable and guaranteed. It doesn't matter if returning std::optional takes ten times as long as using exceptions in non-error situations, if it means you avoid the possibility of suddenly taking a thousand times as long, or the even worse possibility of not knowing how long the exception handling will take. Requirements about predictable and limited timing, even in the face of some kinds of problems or errors, are common in many types of coding. It doesn't have to be critical to live and health - it can be critical to business and economic effects too. And it can be critical to software being acceptable to users - games players are not keen on unexpected pauses in the middle of battles. > cost of exceptions is very much fixed by the implementation, and not as > controllable. If your usage matches the cases that the implementation > optimized for, it can be good, if not, it may not be so good. Absolutely. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 01 11:43AM +0100 > b. reduce the comment to just "IEEE754", or > c. leave it as it is. > Thank you. Would you like us to train you on how to use the toilet too or do you prefer wearing diapers? Do you still require a bib when eating? When are you going to big school? /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 01 12:48PM +0200 > I have this line > static_assert(::std::numeric_limits<float>::is_iec559,"Only IEEE754 supported"); That's not necessary because no one will write a C++17-conformant compiler for an ancient architecture without IEEE-754-floating-points and is realistic to expect that there will be never any future CPU that implements floats differently. Its just one of those compulsive nerd-assessments. |
| rick.c.hodgin@gmail.com: Sep 01 04:16AM -0700 On Sunday, September 1, 2019 at 6:43:59 AM UTC-4, Mr Flibble wrote: > "Snakes didn't evolve, instead talking snakes with legs changed into > snakes." - Rick C. Hodgin https://www.youtube.com/watch?v=k5wknazzz9w Every post. Every time you read your signature with or without that part: Jesus is calling you to repent. Jesus is calling you to be saved. Jesus is calling you to be a part of His eternal Kingdom of love and peace and joy unspeakable. "I stand at the door and knock," He says. Knock knock. -- Rick C. Hodgin |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 01 01:15PM +0100 > and peace and joy unspeakable. > "I stand at the door and knock," He says. > Knock knock. No, every time I read that signature I think, oh yeah, Rick the fucktard who thinks Satan invented fossils. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 01 02:56PM +0200 > Would you like us to train you on how to use the toilet too or > do you prefer wearing diapers? Do you still require a bib when > eating? When are you going to big school? The issue he is talking about might be a bit nerdish, but your comment is rather childish. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 01 02:20PM +0100 On 01/09/2019 13:56, Bonita Montero wrote: >> eating? When are you going to big school? > The issue he is talking about might be a bit nerdish, > but your comment is rather childish. Virtually all of his posts (including this one) are feeble attempts at disguised advertising for his library that serves no purpose other than to add some bulk to his website that promotes misogyny and homophobia. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 01 03:35PM +0200 > Virtually all of his posts (including this one) are feeble attempts at > disguised advertising for his library that serves no purpose other than > to add some bulk to his website that promotes misogyny and homophobia. Maybe, but your style of response isn't mature. |
| Robert Wessel <robertwessel2@yahoo.com>: Sep 01 09:21AM -0500 On Sun, 1 Sep 2019 12:48:07 +0200, Bonita Montero >and is realistic to expect that there will be never any future CPU >that implements floats differently. >Its just one of those compulsive nerd-assessments. While IBM has not yet released a C++17 version of XL C/C++ for z/OS, they are widely expected to, and for it, like the C++11 version, to support both IEEE and IBM S/360 hex style floats via a compiler option. In any event, numeric_limits::is_iec559 is C++11, and supported on that compiler as you expect for both hex and binary FP. |
| woodbrian77@gmail.com: Sep 01 09:53AM -0700 > they are widely expected to, and for it, like the C++11 version, to > support both IEEE and IBM S/360 hex style floats via a compiler > option. In any event, numeric_limits::is_iec559 is C++11, and I'm not sure what that last part means. For now I've changed the line to option b: static_assert(::std::numeric_limits<float>::is_iec559,"IEEE754"); To rephrase my original question, do you use comments at all with static_assert if you are using 2017 C++? Brian Ebenezer Enterprises - In G-d we trust. https://github.com/Ebenezer-group/onwards |
| Ian Collins <ian-news@hotmail.com>: Sep 02 07:30AM +1200 On 02/09/2019 01:35, Bonita Montero wrote: >> disguised advertising for his library that serves no purpose other than >> to add some bulk to his website that promotes misogyny and homophobia. > Maybe, but your style of response isn't mature. Neither is deliberately snipping attributions... -- Ian. |
| Richard Damon <Richard@Damon-Family.org>: Sep 01 03:39PM -0400 > Brian > Ebenezer Enterprises - Enjoying programming again. > http://webEbenezer.net Personally, I would be tempted to leave it as is. Making useful error messages is generally good. Making the Error comment optional might make some sense if the Error Condition is fully self documenting, but the linkage between IEC559 and IEEE754 isn't inherently obvious. I might even extend the error message to something more verbose, like IEEE754/IEC559 Floating point assumed and needed After all, a static_assert imposes zero run time costs, just minimal text space in the file and virtually zero processing time during compilation. Treat it as file documentation for the requirements of the system, and make it readable. |
| 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