3 ms·

You avoid any but trivial constructors an place all failable logic in a separate init()

by rmholt 2y ago

MauranKilom 2y ago
In other words, you introduce an invalid state to every object and make constructing objects a lot more cumbersome. The first is the exact opposite of the (imo highly desirable) "make invalid states unrepresentable" principle, and the second is also a pretty extreme cost to productivity. I wouldn't say this is never worth it, but it's a very high price to pay.
- rmholt 2y ago
  I know it sucks but such is the price of C++ I'm not saying it's perfect but it's better than dealing with C++ exceptions. At least with error codes you can manually do some printing to find out what went wrong. With C++ exceptions you don't even get a line number or a stack trace.
- ahoka 2y ago
  Well, to really implement that principle, you need a much better type system than C++ has anyways. You also don’t have to make the anemic constructor public.
- Matheus28 2y ago
  A better solution than what rmholt said is to have a static method that returns std::optional<T>. This way if T exists, it's valid. Later you get into another whole debate about movable types and what T should be once it's moved from (for example if you want to turn that std::optional<T> into a std::shared_ptr<T>), if it only has non-trivial constructors. An idea that just popped into my head would be to have a T constructor from std:optional<T>&&, which moves from it and resets the optional. But then it's not a real move constructor. With move constructors, a lot of times you just have to accept they'll have to leave the other object in some sort of empty or invalid state.
- pandaman 2y ago
  You do get invalid states with exceptions in much worse way. Think exception thrown from a constructor, or, even better, from a constructor of one of the members even before the constructor's body is reached. Not to mention managing state becomes much more complicated when every statement can cause stack unwinding unexpectedly.

You avoid any but trivial constructors an place all failable logic in a separate init()

by rmholt 2y ago

You avoid any but trivial constructors an place all failable logic in a separate init()

In other words, you introduce an invalid state to every object and make constructing objects a lot more cumbersome. The first is the exact opposite of the (imo highly desirable) "make invalid states unrepresentable" principle, and the second is also a pretty extreme cost to productivity. I wouldn't say this is never worth it, but it's a very high price to pay.

rmholt 2y ago
I know it sucks but such is the price of C++ I'm not saying it's perfect but it's better than dealing with C++ exceptions. At least with error codes you can manually do some printing to find out what went wrong. With C++ exceptions you don't even get a line number or a stack trace.
ahoka 2y ago
Well, to really implement that principle, you need a much better type system than C++ has anyways. You also don’t have to make the anemic constructor public.
Matheus28 2y ago
A better solution than what rmholt said is to have a static method that returns std::optional<T>. This way if T exists, it's valid. Later you get into another whole debate about movable types and what T should be once it's moved from (for example if you want to turn that std::optional<T> into a std::shared_ptr<T>), if it only has non-trivial constructors. An idea that just popped into my head would be to have a T constructor from std:optional<T>&&, which moves from it and resets the optional. But then it's not a real move constructor. With move constructors, a lot of times you just have to accept they'll have to leave the other object in some sort of empty or invalid state.
pandaman 2y ago
You do get invalid states with exceptions in much worse way. Think exception thrown from a constructor, or, even better, from a constructor of one of the members even before the constructor's body is reached. Not to mention managing state becomes much more complicated when every statement can cause stack unwinding unexpectedly.