Hacker News Reader

Comment by pjmlp | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com