- "std::format in C++20" by Peter Gottschling - 12 Updates
- C++ 20 modules - 2 Updates
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Oct 07 04:51PM -0700 >>compelling. > Juha touched on 1. to_string() or even "cast" operator overrides > in some cases. Yes, but that creates a strong distinction between types for which printf already has defined formats and types for which it doesn't. There's no way to tell printf to accept a user-defined type directly. > for 2, gcc and clang and others support the ability warn > if the printf specifier doesn't match the type of the > associated argument. Yes, but only if the format string is a string literal. There are workaround for printf's flaws. And yes, sometimes that's good enough, but they're only workarounds. (And yes, I'm aware of the problems with "<<".) -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Juha Nieminen <nospam@thanks.invalid>: Oct 08 06:28AM > Juha touched on 1. to_string() or even "cast" operator overrides > in some cases. You didn't address any of my objections to that solution. |
| Bo Persson <bo@bo-persson.se>: Oct 08 09:26AM +0200 On 2020-10-07 at 19:18, Mr Flibble wrote: > I would argue having a file not found exception when attempting to open > a file is perfectly acceptable: where does it say that all exceptions > must be regarded as fatal? The filesystem library has two versions of most functions, one that uses an error code and one that throws an exception. The idea is that if a failure condition is probable and easy to handle locally, you can use the error code version and (perhaps) retry the operation. That saves you from having a potentially expensive try-catch clause that triggers too often. If the error is not expected, or cannot be handled anyway, you can let the exception propagate and hope that some other part of the program knows what to do. Bo Persson |
| Juha Nieminen <nospam@thanks.invalid>: Oct 08 07:34AM > requests for open source projects to support throws become calls to > std::terminate, and the extent to which projects have moved to > accommodate that. I think that error handling of any kind is almost non-existent in 99.9% of software projects out there (hobby or professional). Look at pretty much any software project out there with source code available, be it C or C++, and you'll probably find zero error handling, for example related to running out of memory, or writing to a file failing for some reason. (Perhaps the only kind of error handling that you ever see is checking if opening a file succeeded or not, and even this only because it's so common to try to open a file that doesn't exist. I'm sure that if this were a very rare event, most programs wouldn't even bother doing that, and would happily misbehave if it ever happened.) I would bet that if you take almost any software out there that, for example, reads or writes files, it will not check for every read or write that it succeeded, or any other operation that it does (such as fseed() or ftell()). Heck, almost none of them probaby don't even bother checking if closing the file succeeded. Of course one of the most likely scenarios for a catastrophic failure that a program may experience is running out of memory, and also one of the things that almost no program ever checks. In C this is particularly problematic because in principle you would need to make that check in myriads of places. The advantage of C++ exceptions is that it makes such checks much easier. You don't need to litter your code with hundreds and hundreds of checks to see if a memory allocation failed. Instead, you can strategically place a few catch blocks, and have the program report the problem and end gracefully if it happens. But, of course, 99.9% of C++ programmers don't bother doing that, no matter how easy it is. Just have the program crash for an unknown reason. |
| Bo Persson <bo@bo-persson.se>: Oct 08 09:51AM +0200 > } > I doubt if the primary motivation here is ease of handling, as > opposed to allowing exceptions to be avoided altogether. That's not what the standard document says: "29.11.6 Error reporting [fs.err.report] Filesystem library functions often provide two overloads, one that throws an exception to report file system errors, and another that sets an error_code. [Note: This supports two common use cases: — Uses where file system errors are truly exceptional and indicate a serious failure. Throwing an exception is an appropriate response. — Uses where file system errors are routine and do not necessarily represent failure. Returning an error code is the most appropriate response. This allows application specific error handling, including simply ignoring the error. —end note] > For those that have to disable exceptions, which includes a significant portion of > the C++ community including many game developers, an std::terminate seems a > heavy price to pay for a format error. For the rest of us, having a type mismatch between the format string and some other std::format argument is one of those "truly exceptional" conditions. It should never, ever, happen in production code, so the exception is not going to throw. Having an exception that never throws is a lot cheaper than actually verifying the return code at each call of the funtion. Unless, of course, we just ignore the error. Having worked for a bank, I can assure you that a format error can be an extremely serious problem. Imagine printing the wrong number of digits on a check. :-( Bo Persson |
| David Brown <david.brown@hesbynett.no>: Oct 08 11:06AM +0200 On 08/10/2020 09:34, Juha Nieminen wrote: > exist. I'm sure that if this were a very rare event, most programs > wouldn't even bother doing that, and would happily misbehave if it > ever happened.) It is not unreasonable to prioritise realistic situations. Baring runaway memory leaks (and those are bugs, not planned error handling situations) or /extremely/ demanding software, programs on PC's don't run out of memory. It simply doesn't happen. So any code that you write to detect and handle out of memory errors is wasted effort, detracts from the readability of the code, and is untestable. And /if/ an allocation fails, your program is going to hit an OS-detectable fault as it tries to access non-existent memory. A clean OS-controlled crash is fine in those truly exceptional circumstances for many programs. For /some/ code it makes sense to track memory allocation failures, but for most (especially most application-level code), ignoring it is fine. To a lesser degree, but with the same principle, for a lot of programs it is acceptable to assume that if you can open a file for writing, then writes to it will succeed. |
| Manfred <noname@add.invalid>: Oct 08 02:25PM +0200 On 10/8/2020 9:34 AM, Juha Nieminen wrote: >> accommodate that. > I think that error handling of any kind is almost non-existent in 99.9% of > software projects out there (hobby or professional). That's not my experience, for professional code including open source. Obviously toy hobby programs don't matter. > write that it succeeded, or any other operation that it does (such as > fseed() or ftell()). Heck, almost none of them probaby don't even bother > checking if closing the file succeeded. Ditto > things that almost no program ever checks. In C this is particularly > problematic because in principle you would need to make that check in > myriads of places. Not really. IME good projects tend to centralize OS calls, so you don't find bare 'malloc' calls spread all over the code. They are rather confined inside some wrapper or allocation module. There are multiple reasons for this. One is error handling (could be as simple as log and exit), another is performance, since these are expensive calls and the design wants to keep them under control. > gracefully if it happens. > But, of course, 99.9% of C++ programmers don't bother doing that, no matter > how easy it is. Just have the program crash for an unknown reason. Again, not my experience. But I see that this might be an habit for some Java and C# (.NET) programmers - it's not that uncommon to find applications written in those languages that more or less frequently prompt the user with some incomprehensible message and terminate - very disappointing, and rude (one of the reasons I like C++ better than those). Apart of considerations on coding discipline, this may be an argument against exceptions, since in those languages they are de facto the /only/ error handling facility. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 08 02:31PM +0200 > I think a better argument is if handling of the error is likely > to be handled locally, rather than after a lot of stack unwinding. That depends on the type of error. I/O-errors and memor -errors are the best to be handled in an outer scope. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 08 05:40AM -0700 On Thursday, 8 October 2020 01:08:28 UTC+3, Scott Lurndal wrote: > has been compelling enough to switch to the "<<" nonsense. > It may be compelling for someone just learning the language, > perhaps, but for an experienced programmer? it's just a blip. Like usual. Topic was that new std::print. But no much of it. It anyway degraded into typical irrelevant comparison what is worse printf or << plus point that noobs don't deserve anything better than we had for decades. I think Neanderthals went extinct because of such stagnated view. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 08 10:03AM -0400 On 10/8/20 3:34 AM, Juha Nieminen wrote: ... > write that it succeeded, or any other operation that it does (such as > fseed() or ftell()). Heck, almost none of them probaby don't even bother > checking if closing the file succeeded. Because most of my code has involved batch processing, it didn't matter much how quickly it responded to a failure on output. The only thing that could be done about such an error is send a copy of the input files to me for testing to determine why it failed, and the resulting delay could be hours or days, regardless of whether or not the program continued processing after the error. Since a stream's error indicator is sticky, it was acceptable to not bother checking for an output error until just before closing the file. This doesn't work on input, since failing to check for I/O errors during input usually results in unexpected behavior if such an error does occur. > gracefully if it happens. > But, of course, 99.9% of C++ programmers don't bother doing that, no matter > how easy it is. Just have the program crash for an unknown reason. There's some truth in that - most of the software I've seen that was designed by other people fits that description to some degree. However, I would not consider software that had all of those problems to be "professional". Software whose design was entirely my own responsibility is careful about every single issue you describe, including try-catch around main(). As a result, some people have gotten the impression that the primary purpose of my code was to produce error messages. I even once had a subordinate who prepared a test plan for one of my modules that triggered every single error condition, but which failed to confirm whether the code handled non-error conditions correctly. |
| scott@slp53.sl.home (Scott Lurndal): Oct 08 03:28PM >software projects out there (hobby or professional). >Look at pretty much any software project out there with source code >available, be it C or C++, and you'll probably find zero error handling, That has not been my experience with any professional C++ application (including two operating systems, a hypervisor, and a large system used to generate X.509 certificates for millions of websites). A very typical example: uint8 *bp = &e_buffer.at(cmd.s.buf_index); ssize_t diag = ::pwrite(edp->ed_fd, bp, size, offset); if (diag != static_cast<ssize_t>(size)) { e_trace->trace(TRACE_ALWAYS, "Unable to write %zu bytes to %s@0x%lx: %s\n", (size_t)512, edp->ed_path, offset, (errno == EBADF)?"Use 'control connect' command to associate disk file with EMMc card" :strerror(errno)); return false; } |
| Melzzzzz <Melzzzzz@zzzzz.com>: Oct 08 08:01PM > worse printf or << plus point that noobs don't deserve anything > better than we had for decades. I think Neanderthals went extinct > because of such stagnated view. I think that format is good thing. Petty that it didn't arrive earlier... -- current job title: senior software engineer skills: c++,c,rust,go,nim,haskell... press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Thiago Adams <thiago.adams@gmail.com>: Oct 08 06:29AM -0700 Does modules in C++ specify how they could be distributed ? Something like a package? Does modules have influence in the build? For instance, if I include a module the compilers knows what lib it has to include? I cannot see any motivation for modules apart of (fast compilation and hiding macros). Can someone help ? Some links or documentation? |
| David Brown <david.brown@hesbynett.no>: Oct 08 05:30PM +0200 On 08/10/2020 15:29, Thiago Adams wrote: > and hiding macros). > Can someone help ? > Some links or documentation? I think compiled modules are considered compiler-specific, and are not portable. The disadvantages of this are clear - the advantages are that they can include extra information in internal formats, such as LTO data or compiler-specific extensions. The motivation for modules is better modularisation - as you say, faster compilation and hiding macros (and other internal symbols). This in turn makes it more practical to have header-only (or header-mostly) files and libraries, which are easier to distribute, and give more compile-time checking and more optimisation, but are costlier for compilation. I don't think modules are a revolution, but they make some things a bit neater and a bit faster. That's my understanding, anyway - without having used them as yet. |
| 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