4 ms·

> So don't use std::vector? Or std::unordered_map? Or std::string? These are all perfectly fine classes, banning them makes no sense at all. Orthodox C++ bans

by pansa2 6y ago

> So don't use std::vector? Or std::unordered_map? Or std::string? These are all perfectly fine classes, banning them makes no sense at all. Orthodox C++ bans exceptions, so if an allocation failure occurs within one of those classes, the only thing your program can do is abort. That’s fine for some programs - Google’s C++ style guide takes this approach, as does LLVM. But for other programs, where aborting on allocation failure is not acceptable, there’s no way to use those classes without using exceptions.

gumby 6y ago
> Google’s C++ style guide takes this [ no exceptions; libraries abort ] approach Note the style guide says they’d rather use exceptions but had too much legacy code (and now must have a couple of orders of magnitude of it by now): “On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. … Because most existing C++ code at Google is not prepared to deal with exceptions [don’t use them]” Google’s non use of exceptions is often used as justification for not using them either, by people who haven’t actually read Google’s style guide. Also: few of us have Google sized problems.
- kllrnohj 6y ago
  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.
kllrnohj 6y ago
> But for other programs, where aborting on allocation failure is not acceptable Sure but that seems like the edge case not the general case? Nearly any desktop or mobile app or game won't have any such constraints, for example. And you've also got overcommit to deal with on those platforms, so it's not like your allocation failure will actually happen at malloc time either. So outside of embedded, which tends to have a variety of constraints, what even pretends to handle allocation failures across the entire program?
- ape4 6y ago
  You can supply your own allocator for the STL
  - gmueckl 6y ago
    Not really. You can supply alloctors to contai ers, but it becomes iffy for strings. Custom allocator support for std::function was removed in C++17. And there is no way that I am aware of to use custom allocators for the std::shared_ptr refcounters.
    - kllrnohj 6y ago
      There is, allocate_shared takes an allocator: https://en.cppreference.com/w/cpp/memory/shared_ptr/allocate_shared https://en.cppreference.com/w/cpp/memory/shared_ptr/allocate... I'm not entirely sure why you'd want a custom allocator for shared_ptr, though.
      - gmueckl 6y ago
        It is quite common in certain contexts to allow the user of a library to provide their own custom allocator. And this would be kind of pointless if some allocations circumvent that, wouldn't it? The deeper rationale is that some systems like to assign fixed memory pools to subsystems. These may be reset or destroyed at certain points in the applications life cycle and the general expectation is that this frees all memory used by said subsystem. If you still want to use the STL in that context, you need to provide custom allocators for everything that potentially allocates.

by pansa2 6y ago

gumby 6y ago

> Google’s C++ style guide takes this [ no exceptions; libraries abort ] approach Note the style guide says they’d rather use exceptions but had too much legacy code (and now must have a couple of orders of magnitude of it by now): “On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. … Because most existing C++ code at Google is not prepared to deal with exceptions [don’t use them]” Google’s non use of exceptions is often used as justification for not using them either, by people who haven’t actually read Google’s style guide. Also: few of us have Google sized problems.

kllrnohj 6y ago
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.

kllrnohj 6y ago

> But for other programs, where aborting on allocation failure is not acceptable Sure but that seems like the edge case not the general case? Nearly any desktop or mobile app or game won't have any such constraints, for example. And you've also got overcommit to deal with on those platforms, so it's not like your allocation failure will actually happen at malloc time either. So outside of embedded, which tends to have a variety of constraints, what even pretends to handle allocation failures across the entire program?

ape4 6y ago
You can supply your own allocator for the STL
- gmueckl 6y ago
  Not really. You can supply alloctors to contai ers, but it becomes iffy for strings. Custom allocator support for std::function was removed in C++17. And there is no way that I am aware of to use custom allocators for the std::shared_ptr refcounters.
  - kllrnohj 6y ago
    There is, allocate_shared takes an allocator: https://en.cppreference.com/w/cpp/memory/shared_ptr/allocate_shared https://en.cppreference.com/w/cpp/memory/shared_ptr/allocate... I'm not entirely sure why you'd want a custom allocator for shared_ptr, though.
    - gmueckl 6y ago
      It is quite common in certain contexts to allow the user of a library to provide their own custom allocator. And this would be kind of pointless if some allocations circumvent that, wouldn't it? The deeper rationale is that some systems like to assign fixed memory pools to subsystems. These may be reset or destroyed at certain points in the applications life cycle and the general expectation is that this frees all memory used by said subsystem. If you still want to use the STL in that context, you need to provide custom allocators for everything that potentially allocates.