3 ms·

The only "real" issue with exceptions is binary size, and binary size does seem to be a rather specific goal of Orthodox C++ even though it's not explicit about

The only "real" issue with exceptions is binary size, and binary size does seem to be a rather specific goal of Orthodox C++ even though it's not explicit about that. But on any desktop or server deployment binary size is also so incredibly irrelevant it's not a good justification. On mobile maybe, but it's questionable. For embedded definitely, though.

patrec 6y ago
https://twitter.com/timsweeneyepic/status/1223077404660371456 https://twitter.com/timsweeneyepic/status/122307740466037145...
- kllrnohj 6y ago
  While interesting I guess that sounds like a straightforward compiler bug not a problem with the feature overall. Unless there's some missing nuance why 'noexcept' was apparently being ignored which would need further investigation.
gmueckl 6y ago
Exceptions have hidden costs that are hard to spot. For example, generated assembly for C++ code with or without noexcept can be quite different. Part of the reason is that DFA based optimizations get overwhelmed by the number of implied execution paths when exceptions may be thrown. So the optimizer essentially is forced give up more often, resulting in slower code for the normal case. This is orthogonal to any binary size issues from linking the runtime support for exceptions.
- kllrnohj 6y ago
  Of course, but that's comparing error handling code with non-error handling code. The comparison you need to make is instead exceptions vs. return values. Unless you're going to argue all errors should abort by default or similar. I do wish noexcept had better support, or was even the default (C++ and wrong defaults, a tale as old as time). But it's disingenuous to compare exceptions against nothingness.
  - gmueckl 6y ago
    No, this holds in a fair comparison with manual error checking. In the presence of possible exceptions, the compiler has to make the assumption that any nontrivial expression can throw, especially if its implementation is opaque at the callsite. With explicit error handling, this is reduced to those checkpoints that are inserted manually, which are generally fewer. If you call a function within the condition of an if statement, the compiler needs to conservatively assume that the execution flow from there is either to the rest of the conditionsl or to either one of the catch blocks or the functions' stack unwinding. If there cannot be an exception, the execution flow has none of these additional branches that bog down the DFA.

patrec 6y ago

https://twitter.com/timsweeneyepic/status/1223077404660371456 https://twitter.com/timsweeneyepic/status/122307740466037145...

kllrnohj 6y ago
While interesting I guess that sounds like a straightforward compiler bug not a problem with the feature overall. Unless there's some missing nuance why 'noexcept' was apparently being ignored which would need further investigation.

gmueckl 6y ago

Exceptions have hidden costs that are hard to spot. For example, generated assembly for C++ code with or without noexcept can be quite different. Part of the reason is that DFA based optimizations get overwhelmed by the number of implied execution paths when exceptions may be thrown. So the optimizer essentially is forced give up more often, resulting in slower code for the normal case. This is orthogonal to any binary size issues from linking the runtime support for exceptions.

kllrnohj 6y ago
Of course, but that's comparing error handling code with non-error handling code. The comparison you need to make is instead exceptions vs. return values. Unless you're going to argue all errors should abort by default or similar. I do wish noexcept had better support, or was even the default (C++ and wrong defaults, a tale as old as time). But it's disingenuous to compare exceptions against nothingness.
- gmueckl 6y ago
  No, this holds in a fair comparison with manual error checking. In the presence of possible exceptions, the compiler has to make the assumption that any nontrivial expression can throw, especially if its implementation is opaque at the callsite. With explicit error handling, this is reduced to those checkpoints that are inserted manually, which are generally fewer. If you call a function within the condition of an if statement, the compiler needs to conservatively assume that the execution flow from there is either to the rest of the conditionsl or to either one of the catch blocks or the functions' stack unwinding. If there cannot be an exception, the execution flow has none of these additional branches that bog down the DFA.