4 ms·

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 f

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.

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.