| woodbrian77@gmail.com: Aug 31 03:55PM -0700 Shalom I have this line static_assert(::std::numeric_limits<float>::is_iec559,"Only IEEE754 supported"); in my library: https://github.com/Ebenezer-group/onwards . I wrote that line when I was using 2011 C++ and the comment was required. Now I require 2017 C++ and am trying to decide between: a. remove the comment b. reduce the comment to just "IEEE754", or c. leave it as it is. Thank you. Brian Ebenezer Enterprises - Enjoying programming again. http://webEbenezer.net |
| Anton Shepelev <anton.txt@gmail.com>: Aug 31 03:05AM +0300 Bonita Montero to already5chosen: > > EH is bad not because it's slow or costly, but because > > of its messy semantics. > What's messy with the semantics? By looking at any piece of contiguous code you can't say where its execution is going to be suddenly interrupted and jump to another unobvous place. Code with exceptions is not local because its execution depends on any try blocks anywhere up the call stack. Code with exceptions is not transparent, because it hides the error-handling part of the algorithm, and incomplete information is akin to a lie. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived] |
| Ian Collins <ian-news@hotmail.com>: Aug 31 12:18PM +1200 On 31/08/2019 12:05, Anton Shepelev wrote: > anywhere up the call stack. Code with exceptions is not > transparent, because it hides the error-handling part of the > algorithm, and incomplete information is akin to a lie. You could equally say that code with exceptions emphasises the error handling be concentrating it in one place. Often a process with many steps either works or fails, so handling the errors in one place makes sense. Throwing exceptions also makes the error handling easier to spot, you just look for the throws. -- Ian. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 11:43AM +0200 > By looking at any piece of contiguous code you can't say > where its execution is going to be suddenly interrupted > and jump to another unobvous place. The code that throws an exception doesn't need to know where the exception is caught. |
| "Öö Tiib" <ootiib@hot.ee>: Aug 31 04:50AM -0700 On Friday, 30 August 2019 09:13:33 UTC+3, Mel wrote: > That's Rust advantage. Returnig discriminated union is right way for > handling errors. Rust has syntactic sugar in that. Latest proposal > for c++ exceptions leans toeard that solution. Perhaps different people think of error handling differently. I learned programming using BASIC interpreter in eighties and there was ERROR statement for generating errors and ON ERROR GOTO statement for trapping those to handler. Logic was to keep the already messy algorithms expressed in BASIC cleaner by handling errors in separate place. C and C++ with no error handling in language and most errors just left to be undefined behavior felt seriously inferior because of that. When Microsoft added SEH exceptions to both C and C++ in nineties then it felt good extension. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 31 01:20PM +0100 On 30/08/2019 12:08, David Brown wrote: > when there are no errors, than other handling techniques for typical > code on PC's". What I am /not/ happy with is "Exception handling is > faster than other error return techniques". That statement just shows us that you are clueless on the subject of exceptions. Firstly exceptions are not just for errors. Secondly manually propagating an error code up the stack manually translating to make it suitable for one abstraction layer to the next is both an antiquated way of doing things and a fucktarded way of doing things. If you like error codes so much then stick to fucking C. /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." |
| Paavo Helde <myfirstname@osa.pri.ee>: Aug 31 05:17PM +0300 On 31.08.2019 3:05, Anton Shepelev wrote: > By looking at any piece of contiguous code you can't say > where its execution is going to be suddenly interrupted and > jump to another unobvous place. In C++ this is a no-brainer, you don't need to know or care where the code execution can be interrupted. This is because every allocated resource is protected and released by RAII automatically, regardless of if there is an exception or not. This means using things like std::make_unique() instead of new, etc. IOW, in C++ you just code with the assumption that about every line can throw an exception, if not now, then in the future. There are only some special places where one needs to care about thrown exceptions, namely noexcept functions like destructors, swappers and like. With proper RAII very few classes need such functions. > anywhere up the call stack. Code with exceptions is not > transparent, because it hides the error-handling part of the > algorithm, and incomplete information is akin to a lie. This might sound nice in theory, but in reality the error handling part cannot be part of the actual code because more often than not this code has no idea how to react to the error. Let's say an input data file cannot be opened by some number-crunching library. How should it handle this error? Should it abort the whole program, or should it pop up a dialog asking the user to correct the problem and retry? What if it runs in a web server where there is no user to click on the dialog? The error handling logic is altogether at a different level than the low-level code which tries to open the file, and the low-level code cannot and should not contain any "handling" of such errors, it should just report them to the caller. Exceptions are the most convenient way for doing this, in particular they can easily encapsulate much more detailed information about the problem than just some cryptic error code. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 04:28PM +0200 > for doing this, in particular they can easily encapsulate much more > detailed information about the problem than just some cryptic error > code. What I don't like with C++ is that exceptions aren't usually concatenated as like in Java, which is good for debugginig-purposes. In Java you throw a highly specific checked exception-type at the point where the error occurs and the exception might get caught up the call-stack and concatenated into an more general exceptiont -type. I.e. a JDBC-driver might throw a I/O-error when the socket is dropped by the OS, there is a specific socket exception-class thrown and further up the call -levels this is wrapped in a more general JDBC-error-class; this is done in this way: "throw new OuterExceptionClass( inner );". In C++ this isn't directly possible because new might throw bad _alloc. The only way I can imagine to do this is to have thread -local / static exception-objects which are thrown when appropriate. |
| Manfred <noname@invalid.add>: Aug 31 06:03PM +0200 On 8/30/19 1:47 PM, Bonita Montero wrote: [...] >>> -collapse doesn't count. >> Incorrect. > No, correct. No, incorrect. >> reliability systems. > When you have a resource or I/O-collapse, you don't have reliability > anyway. Correctness of behavior (which includes controlled performance) under stress conditions (including resource exhaustion) is a critical requirement of high reliability systems - that's what they are made for. It appears you don't have much experience with such systems. >> that can be used, without leading to any inefficiency or bloat. > Almost the whole standard-libary uses an allocaor which might > throw bad_alloc; not to use the standard-library isn't really C++. Incorrect as well. As a first one can replace the allocator in all standard library facilities, and more generally one can use many features of C++ (e.g. templates, generic programming, metaprogramming, constexpr (aka compile-time processing), ...) with no need for any runtime-hungry technology. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 31 06:21PM +0200 > stress conditions (including resource exhaustion) is a critical > requirement of high reliability systems - that's what they are made for. > It appears you don't have much experience with such systems. The correctnes is also guaranteed with exceptions. But they might have higher runtime-overhead when being thrown. But this absolutely doesn't matter because the resouce- or I/O-collapse case isn't performance -relevant. So I'm not incorrect. And consider what you would do with return-codes: you would evaluate them at every call-level and convert them into a special return-code appropriate for the function-level. This is also likely to be very inperformant. >> Almost the whole standard-libary uses an allocaor which might >> throw bad_alloc; not to use the standard-library isn't really C++. > Incorrect as well. N, true. > As a first one can replace the allocator in all standard library > facilities, ... Doing this without throwing an exception like bad_alloc from an allo- cator doesn't work. This is because there is no way to signal a memory -collapse differently than through throwing an exception on the usual container-operations. Dropping the facilities that might throw excep- tions isn't really C++ |
| David Brown <david.brown@hesbynett.no>: Aug 31 11:39PM +0200 On 30/08/2019 13:47, Bonita Montero wrote: >> problem - that is critical. > The case when an exception is thrown isn't performance-relevant > as this occurs when there's an resource- or I/O-collapse. As seems to be the case depressingly often, you are over-generalising from certain types of software. 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. For real-time programming, it doesn't matter how fast the usual situation runs. It matters that even in the worst case, you know how long the code will take. It is a world outside your experience and understanding, apparently, but it is a vital part of the modern world. >> Fair enough - though convenience is also a subjective matter. > That's rather not subjective here because evaluating return-codes on > every call-level is a lot of work. Again, you don't see the big picture and think that your ideas cover everything. Dealing with return codes on every call level is only a lot of work if 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. By being explicit and clearly limited, return code error handling is far simpler to examine and understand, and it is far easier to test functions fully when you don't have to take into account the possibility of an unknown number of unknown exceptions passing through. As I have said, different ways of handling errors have their pros and cons, and there is no one way that is best for all cases. >> functions compiled without knowledge of the exceptions - such as C >> functions compiled by a C compiler. > Can you read what I told above? I elaborated on what you wrote. >>> -collapse doesn't count. >> Incorrect. > No, correct. I'm sorry, but you are making bald statements with apparently no knowledge or experience in the area. >> reliability systems. > When you have a resource or I/O-collapse, you don't have reliability > anyway. You do understand that people use exceptions for a variety of reasons, don't you? You do realise that people sometimes write safe and reliable software that is designed to deal with problems in a reasonable fashion? If "throw an exception" simply means "there's been a disaster - give up on reliability, accept that the world has ended and it doesn't matter 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. >> that can be used, without leading to any inefficiency or bloat. > Almost the whole standard-libary uses an allocaor which might > throw bad_alloc; not to use the standard-library isn't really C++. That's bollocks on so many levels, it's not worth trying to explain them to you. |
| David Brown <david.brown@hesbynett.no>: Aug 31 11:45PM +0200 On 31/08/2019 14:20, Mr Flibble wrote: >> faster than other error return techniques". > That statement just shows us that you are clueless on the subject of > exceptions. You are jumping in to a discussion without following the details. > Firstly exceptions are not just for errors. I realise that. The discussion was about error handling techniques, including alternatives to exceptions for handling errors. And of course, there is no single definition of "error" anyway - it means different things in different contexts. > manually propagating an error code up the stack manually translating to > make it suitable for one abstraction layer to the next is both an > antiquated way of doing things and a fucktarded way of doing things. It is an excellent way of handling things in some cases. If you had been paying attention and read my posts before replying, you'd have seen I have argued that a variety of techniques can be useful in different cases - exceptions are often a good choice, but they are most certainly not always the right choice. > If > you like error codes so much then stick to fucking C. Don't be such a child. |
| David Brown <david.brown@hesbynett.no>: Sep 01 12:06AM +0200 On 31/08/2019 16:17, Paavo Helde wrote: >> By looking at any piece of contiguous code you can't say >> where its execution is going to be suddenly interrupted and >> jump to another unobvous place. C++ exceptions have been described as "undocumented gotos". The description is, I think, quite fair. That does not necessarily make them a bad thing - they can often be a good choice in coding. Different types of coding need different balances, and programming is always a matter of picking appropriate balances. Sometimes you want automatic and implicit, sometimes you want manual and explicit. C++ offers you much more flexibility than most languages in finding balances that work well for the code you are writing - you learn the options and their pros and cons, and make your choices. > resource is protected and released by RAII automatically, regardless of > if there is an exception or not. This means using things like > std::make_unique() instead of new, etc. RAII to protect resources is not remotely dependent on exceptions : std::optional<int> foo(int x) { auto a = std::make_unique<int>(x); auto b = dosomething(a); if (!b) return std::nullopt; dosomethingelse(a, b); return calc(a); } You don't need exceptions to avoid leaks and tidy up resources - RAII gives you that regardless. Returning with error codes (or std::optional, or new suggestions like "expected", or whatever) is just as good from that viewpoint. > This might sound nice in theory, but in reality the error handling part > cannot be part of the actual code because more often than not this code > has no idea how to react to the error. And therein lies the problem, when you are concerned with being able to be sure your code is correct (both by design, and by testing). > this error? Should it abort the whole program, or should it pop up a > dialog asking the user to correct the problem and retry? What if it runs > in a web server where there is no user to click on the dialog? Separate the concerns. Don't make a function (or class, or unit, or 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. Or make a function that will attempt to read the data from the file and 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. But now, instead of having a function that lives in a happy, optimistic, carefree and unrealistic world, with no sense of responsibility and an "I don't care, it's someone else's problem" attitude, you've got a function that is clear and complete. If there is a problem, it will tell you - and it will do so in a way that you know about and understand, and that you can test. Your function no longer has errors - it has a wider scope of correct, specified, tested and documented, behaviour. (And yes, you can use exceptions for this just as well as other error techniques.) |
| 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. |
