4 ms·

Eh? A lot of modern C++ development explicitly disables exceptions, they are unnecessary whether or not they should be used in practice. For more low-level syst

Eh? A lot of modern C++ development explicitly disables exceptions, they are unnecessary whether or not they should be used in practice. For more low-level systems-y code, there are good reasons to avoid them. While there are arguments over when and how to use exceptions, I think this is the first time I've seen them positioned as a killer feature of C++.

mgaunard 5y ago
Modern C++ is very much about exceptions. Disabling exceptions gives you C with classes, which is the old style. I write ultra low-latency system-level code for HFT, and I certainly use exceptions.
- jandrewrogers 5y ago
  I write ultra high-throughput database kernels. We use just about every feature of C++17 and beyond, particularly since so much of the implementation is generated via metaprogramming scaffolds. I don’t use exceptions at all, mostly because it is a poor abstraction for this type of code. Exceptions aren’t all upside. Clearly, modern C++ has very little to do with exceptions, or I would have required them or found them useful at some point. I’m not saying exceptions are not useful, but their centrality to the language is empirically false given the vast number of modern C++ code bases that don’t use them and lose nothing by it.
  - int_19h 5y ago
    How do you deal with failures to allocate in stdlib?
    - pjmlp 5y ago
      By providing custom allocators? Also when speaking about kernels, it isn't as if the other languages being discussed (including C), make use of their respective stdlib in kernel space.
      - int_19h 5y ago
        How would the custom allocator report the failure to allocate to the container, though?
    - jandrewrogers 5y ago
      Database kernels do virtually no heap allocation as a matter of good design. They also rarely use stdlib containers or anything else that dynamically allocates on the heap outside of the bootstrap context. Virtually all of this memory has to be dynamically pageable to storage (and you can’t use mmap() or virtual memory) which largely precludes using parts of the stdlib that require allocations. They work within a tightly bounded memory footprint plus the stack, and these resource reservations are pretty strongly guaranteed at bootstrap. Even the stack often has analyzable bounds. It is hard to design good schedulers, whence most optimization comes, without these constraints. If your process doesn’t survive allocation in bootstrap then it is badly misconfigured. If it survives bootstrap, then the software has been able to make hard guarantees about its resource constraints; the runtime will optimize to those constraints. Many years ago, given the designs of the time, you had to worry about blowing out the stack memory occasionally in edge cases, but even that isn’t a real problem these days due to changes in how it is done. You would design things this way in any language. The benefit from a software design standpoint is that you can derive an enormous number of invariants from these constraints that can be used to guarantee that the core processes will never experience resource exhaustion. This eliminates a massive number of edge cases that would have to be accounted for if resource exhaustion was detected by testing limits.
masklinn 5y ago
> I think this is the first time I've seen them positioned as a killer feature of C++. It's not a killer feature of C++, it's a requirement, without exceptions you can't have faillible ctors meaning your object lifecycle suddenly becomes a lot more complicated and full of additional traps.
- pjmlp 5y ago
  A requirement for classes using the default memory allocator, there are other ways to design programs, and to allocate memory.
  - masklinn 5y ago
    > there are other ways to design programs, and to allocate memory. I covered this option: > your object lifecycle suddenly becomes a lot more complicated and full of additional traps. because without ctors you don't have object invariants as you have to split instantiation and initialisation, or you have to implement bespoke and unusual strategies drawing you further and further away from anything which could be described as "standard" C++, thus making the advantages of C++ dwindle further into the distance. And all that with, as far as I know, no standard tooling to support you.
    - pjmlp 5y ago
      Those invariants can still be kept by making use of DbC approach, which is anyway a good coding practice. Classe invariants must be kept in each method call, not only constructors and destructors, and again they only matter in classes. C++ is a multi-paradigm language, this is not Python Zen.
      - int_19h 5y ago
        How would you define such a contract without adding a "bool is_valid" (or semantic equivalent) to every object, the constructor of which might fail?

mgaunard 5y ago

Modern C++ is very much about exceptions. Disabling exceptions gives you C with classes, which is the old style. I write ultra low-latency system-level code for HFT, and I certainly use exceptions.

jandrewrogers 5y ago
I write ultra high-throughput database kernels. We use just about every feature of C++17 and beyond, particularly since so much of the implementation is generated via metaprogramming scaffolds. I don’t use exceptions at all, mostly because it is a poor abstraction for this type of code. Exceptions aren’t all upside. Clearly, modern C++ has very little to do with exceptions, or I would have required them or found them useful at some point. I’m not saying exceptions are not useful, but their centrality to the language is empirically false given the vast number of modern C++ code bases that don’t use them and lose nothing by it.
- int_19h 5y ago
  How do you deal with failures to allocate in stdlib?
  - pjmlp 5y ago
    By providing custom allocators? Also when speaking about kernels, it isn't as if the other languages being discussed (including C), make use of their respective stdlib in kernel space.
    - int_19h 5y ago
      How would the custom allocator report the failure to allocate to the container, though?
  - jandrewrogers 5y ago
    Database kernels do virtually no heap allocation as a matter of good design. They also rarely use stdlib containers or anything else that dynamically allocates on the heap outside of the bootstrap context. Virtually all of this memory has to be dynamically pageable to storage (and you can’t use mmap() or virtual memory) which largely precludes using parts of the stdlib that require allocations. They work within a tightly bounded memory footprint plus the stack, and these resource reservations are pretty strongly guaranteed at bootstrap. Even the stack often has analyzable bounds. It is hard to design good schedulers, whence most optimization comes, without these constraints. If your process doesn’t survive allocation in bootstrap then it is badly misconfigured. If it survives bootstrap, then the software has been able to make hard guarantees about its resource constraints; the runtime will optimize to those constraints. Many years ago, given the designs of the time, you had to worry about blowing out the stack memory occasionally in edge cases, but even that isn’t a real problem these days due to changes in how it is done. You would design things this way in any language. The benefit from a software design standpoint is that you can derive an enormous number of invariants from these constraints that can be used to guarantee that the core processes will never experience resource exhaustion. This eliminates a massive number of edge cases that would have to be accounted for if resource exhaustion was detected by testing limits.

masklinn 5y ago

> I think this is the first time I've seen them positioned as a killer feature of C++. It's not a killer feature of C++, it's a requirement, without exceptions you can't have faillible ctors meaning your object lifecycle suddenly becomes a lot more complicated and full of additional traps.

pjmlp 5y ago
A requirement for classes using the default memory allocator, there are other ways to design programs, and to allocate memory.
- masklinn 5y ago
  > there are other ways to design programs, and to allocate memory. I covered this option: > your object lifecycle suddenly becomes a lot more complicated and full of additional traps. because without ctors you don't have object invariants as you have to split instantiation and initialisation, or you have to implement bespoke and unusual strategies drawing you further and further away from anything which could be described as "standard" C++, thus making the advantages of C++ dwindle further into the distance. And all that with, as far as I know, no standard tooling to support you.
  - pjmlp 5y ago
    Those invariants can still be kept by making use of DbC approach, which is anyway a good coding practice. Classe invariants must be kept in each method call, not only constructors and destructors, and again they only matter in classes. C++ is a multi-paradigm language, this is not Python Zen.
    - int_19h 5y ago
      How would you define such a contract without adding a "bool is_valid" (or semantic equivalent) to every object, the constructor of which might fail?