|
| ▲ | drnick1 6 hours ago | parent | next [-] |
| > In low-level systems software, which is a primary use case for C++ I don't this this is true. There is A LOT of C++ for GUI applications, video games, all kind of utilities, scientific computing and others. In fact, I find that the transition to "modern" alternatives from native GUI toolkits in C/C++ has led to a regression in UI performance in general. Desktop programs performed better 20 years ago when everything was written in Win32, Qt, GTK and others and people did not rely on bloated Web toolkits for desktop development. Even today you can really feel how much more snappy and robust "old school" programs are relative to Electron and whatnot. |
| |
| ▲ | saghm 5 hours ago | parent [-] | | To clarify, you think that low-level systems software is only a secondary use case for C++? The part you quoted does not make claims about whether there are other primary use cases, just that low-level systems software is one of them, so it's not clear why it being useful elsewhere is a rebuttal of that. |
|
|
| ▲ | BeetleB 7 hours ago | parent | prev | next [-] |
| > In low-level systems software, which is a primary use case for C++ I can assure you: Most C++ SW is not written for low-level. > exceptions can introduce nasty edge cases that are difficult to detect and reason about. That's true, except for languages that ensure you can't simply forget that something deep down the stack can throw an exception. BTW, I'm not saying C++'s exceptions are in any way good. My point is that exceptions are bad in C++, and not necessarily bad in general. |
| |
| ▲ | beached_whale 7 hours ago | parent | next [-] | | The model of communicating errors with exceptions is really nice. The implementation in C++ ABI's is not done as well as it could be and that results in large sad path perf loss. | |
| ▲ | jandrewrogers 6 hours ago | parent | prev [-] | | > That's true, except for languages that ensure you can't simply forget that something deep down the stack can throw an exception. Sometimes it is not safe to unwind the stack. The language is not relevant. Not everything that touches your address space is your code or your process. Exception handlers must have logic and infrastructure to detect these unsafe conditions and then rewrite the control flow to avoid the unsafety. This both adds overhead to the non-exceptional happy path and makes the code flow significantly uglier. The underlying cause still exists when you don't use exceptions but the code for reasoning about it is highly localized and usually has no overhead because you already have the necessary context to deal with it cleanly. | | |
| ▲ | le-mark 3 hours ago | parent [-] | | > Sometimes it is not safe to unwind the stack. This where garbage collected languages shine. |
|
|
|
| ▲ | kllrnohj 6 hours ago | parent | prev | next [-] |
| If you forget to handle a C++ exception you get a clean crash. If you forget to handle a C error return you get undefined behavior and probably an exploit. Exceptions are more robust, not less. |
| |
| ▲ | nomel 6 hours ago | parent [-] | | Yeap. forgetting to propagate or handle an error provided in a return value is very very easy. If you fail to handle an exception, you halt. | | |
| ▲ | vasilvv 2 hours ago | parent [-] | | For what it's worth, C++17 added [[nodiscard]] to address this issue. |
|
|
|
| ▲ | beached_whale 7 hours ago | parent | prev | next [-] |
| C++ exceptions are fast for happy path and ABI locked for sad path. They could be much faster than they are currently. Khalil Estell did a few talks/bunch of work on the topic and saw great improvements. https://youtu.be/LorcxyJ9zr4 |
| |
|
| ▲ | senfiaj 6 hours ago | parent | prev | next [-] |
| > "In low-level systems software, which is a primary use case for C++, exceptions can introduce nasty edge cases that are difficult to detect and reason about. The benefits are too small to justify the costs to reliability, robustness, and maintainability." Interestingly, Microsoft C / C++ compiler does support structured exception handling (SEH). It's used even in NT kernel and drivers. I'm not saying it's the same thing as C++ exceptions, since it's designed primarily for handling hardware faults and is simplified, but still shares some core principles (guarded region, stack unwinding, etc). So a limited version of exception handling can work fine even in a thing like an OS kernel. |
| |
| ▲ | jandrewrogers 6 hours ago | parent [-] | | FWIW, I think it is possible to make exception-like error handling work. A lot of systems code has infrastructure that looks like an exception handling framework if you squint. There are two main limitations. Currently, the compiler has no idea what can be safely unwound. You could likely annotate objects to provide this information. Second, there is currently no way to tell the compiler what to do with an object in the call stack may not be unwound safely. A lot of error handling code in C++ systems code essentially provides this but C++ exceptions can't use any of this information so it is applied manually. |
|
|
| ▲ | matheusmoreira 7 hours ago | parent | prev [-] |
| Exceptions are actually a form of code compression. Past some break even point they are a net benefit, even in embedded codebases. They're "bad" because the C++ implementation is garbage but it turns out it's possible to hack it into a much better shape: https://youtu.be/LorcxyJ9zr4 |
| |
| ▲ | secondcoming 6 hours ago | parent [-] | | There is no such thing as the 'C++ implementation' of exceptions. Each vendor can do it differently. |
|
