4 ms·

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 i

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.

mgaunard 5y ago
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.
- deschutes 5y ago
  I'm not really concerned who has the most academically pure position on this. The results speak for themselves. The loudmouths and the standards committee seek more concerned with what is possible than solving practical problems. That's why exceptions still don't scale and it's 2021 and C++ still uses a compilation model it inherited from C.
masklinn 5y ago
> 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.
- deschutes 5y ago
  I was responding specifically to the idea that fallible construction requires objects have invalid states. It doesn't. I broadly agree that rust is a better tool and solves a lot of these problems better. That said, I don't think you'll have any better time with "standard" rust and fallible allocation though. These systems projects throw out the whole standard library from what I can tell. Finally. Lots of successful software is written in C++. I think it's foolish to dismiss it because a newer language does it better.

mgaunard 5y ago

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.

deschutes 5y ago
I'm not really concerned who has the most academically pure position on this. The results speak for themselves. The loudmouths and the standards committee seek more concerned with what is possible than solving practical problems. That's why exceptions still don't scale and it's 2021 and C++ still uses a compilation model it inherited from C.

masklinn 5y ago

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

deschutes 5y ago
I was responding specifically to the idea that fallible construction requires objects have invalid states. It doesn't. I broadly agree that rust is a better tool and solves a lot of these problems better. That said, I don't think you'll have any better time with "standard" rust and fallible allocation though. These systems projects throw out the whole standard library from what I can tell. Finally. Lots of successful software is written in C++. I think it's foolish to dismiss it because a newer language does it better.