Hacker News Reader

Comment by jandrewrogers | Hacker News Reader

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++.

View on HN

> 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.

A requirement for classes using the default memory allocator, there are other ways to design programs, and to allocate memory.

> 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.

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.

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?

Model fallible instantiation with factory methods. e.g. Node::make(Args..) -> Result<Node>. It won't always be as efficient or ergonomic but it works. And hey it's c++, you've been conditioned to accept a ton of ceremony to get things done. Famously the bulk of google's code is written without exceptions. And from what I know of it (not much), factory methods are how they model instantiation fallibility.

As a related but separate thought, sometimes adding invalid states to an object is useful. For example, take a look at std::thread::detach. Sometimes you see rvalue qualifiers on such methods (indicating the object has been consumed).

If you consider memory allocation to be infallible, there is a lot of stuff that can be written as pretty normal c++ without exceptions. The STL even pretty much works without throwing given this. If you consider allocation to be fallible you're going to have a bad time with "standard" c++ too.

It's widely accepted by the C++ community that Google's C++ standards are bad. They're more concerned about using a simple subset of the language anyone with minimal C++ training can understand than about writing good C++.

And detaching a thread is pretty much always a bad idea.

> Model fallible instantiation with factory methods. e.g. Node::make(Args..) -> Result<Node>. It won't always be as efficient or ergonomic but it works. And hey it's c++, you've been conditioned to accept a ton of ceremony to get things done. Famously the bulk of google's code is written without exceptions. And from what I know of it (not much), factory methods are how they model instantiation fallibility.

The problem is not the ability to do it but the ability to enforce it. "Just be careful" has not worked, and will keep not working. Google's coding standard has not stopped C++ from causing them problems.

> As a related but separate thought, sometimes adding invalid states to an object is useful. For example, take a look at std::thread::detach. Sometimes you see rvalue qualifiers on such methods (indicating the object has been consumed).

You know what's actually useful and good?

For the object to actually be consumed and not be accessible at all anymore.

> If you consider memory allocation to be infallible

Which you can't in the kernel.

> If you consider allocation to be fallible you're going to have a bad time with "standard" c++ too.

Yes? That would be the point.

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.

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.

How do you deal with failures to allocate in stdlib?

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.

How would the custom allocator report the failure to allocate to the container, though?

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.

Reply on news.ycombinator.com