8 ms·

To be fair, there's a reason for the pattern with init methods you're describing. C++ constructors can't return values. If construction is fallible, the only w

To be fair, there's a reason for the pattern with init methods you're describing. C++ constructors can't return values. If construction is fallible, the only way to communicate the error is via C++ exceptions. If you're in a code base that embraces exceptions, that's fine. But (C++) exceptions kind of suck, so many code bases don't, and then you have to find some alternatives. Over the years, I've increasingly adopted a pattern where the constructor is private in this case and the object construction can be done with static methods - which is a bit more like Rust, actually.

legobmw99 1y ago
This is fine if the method you’re talking about is static — as you point out, it’s really all Rust has — but is absolutely a design mistake if it is not, which I think is what the poster above is referring to. It’s a common anti pattern and means you have an object that is at-best useless and at-worst completely broken after you call the constructor but before you call some member function on it
TuxSH 1y ago
Two-phase initialization also has the added benefit of usually making the object have a constexpr constructor (usually a default constructor) and therefore making it eligible for constinit. That said, construct_at also exists.
- Conscat 1y ago
  Nothing prevents std::vector from having a `constexpr` default-constructor except that it's not considered useful to do if you cannot follow that up with initializing its data in a constant context. For instance, this isn't very useful: constinit vector<int> v; But this would be more so: constinit vector<int> v(16, 1); // Fill with 16 1's. And the reason we can't do this wouldn't be solved by splitting it into multiple functions. EDIT: Actually, come to think of it, C++20's vector already supports the first example. It's just not used much that way because it's not very helpful. https://godbolt.org/z/avY4M9oMK https://godbolt.org/z/avY4M9oMK
EliRivers 1y ago
To be fair, there's a reason for the pattern with init methods you're describing. Without prejudice on any other reasons, the most common reason for this pattern I've seen is people thinking in languages that basically don't have constructors, yet writing C++. It's not a good reason.
- Mond_ 1y ago
  How would you deal with fallible construction of objects while avoiding exceptions in idiomatic C++?
  - metaltyphoon 1y ago
    This was one of the best decisions that Rust and Go did; not have constructors. In C# this is super annoying too, specially when you need an async operation to construct a type. This is usually done by having an private constructor and then using a static public method to create the type.
    - Conscat 1y ago
      Rust and Go have no form of a conversion operator (even if not a constructor), which makes scripting a type system essentially impossible. Numeric libraries in both of those languages are extremely cumbersome, largely for this reason.
      - tialaramex 1y ago
        I don't understand this comment at all. Rust not only has the 'as' operator for this exact purpose, but it also has the suite of traits From, Into, TryFrom and TryInto for the infallible and fallible conversions respectively.
        Conscat 1y ago
        As is an infix operator, it can never be invoked implicitly to draw these relationships between different types.
Conscat 1y ago
> the object construction can be done with static methods I've done that a lot too, but I found that free functions are much better for this than static member functions, because you can't get CTAD from static member functions. For example, with constructors we could write: vector{1, 2, 3}; // deduces vector<int> And with a static member, we would need: vector<int>::init(1, 2, 3); With a free function, we could write: make_vector(1, 2, 3); // returns vector<int>
fooker 1y ago
Right, when construction is fallible you need a factory. Constructors are called in surprising places when running a C++ program. For example, think of a copy constructor failing somewhere far away from the code you are writing. If C++ allowed construction to fail, the control flow of propagating these errors would be tedious and invasive. Hence exceptions as the only way to fail in a construction.

legobmw99 1y ago

This is fine if the method you’re talking about is static — as you point out, it’s really all Rust has — but is absolutely a design mistake if it is not, which I think is what the poster above is referring to. It’s a common anti pattern and means you have an object that is at-best useless and at-worst completely broken after you call the constructor but before you call some member function on it

TuxSH 1y ago

Two-phase initialization also has the added benefit of usually making the object have a constexpr constructor (usually a default constructor) and therefore making it eligible for constinit. That said, construct_at also exists.

Conscat 1y ago
Nothing prevents std::vector from having a `constexpr` default-constructor except that it's not considered useful to do if you cannot follow that up with initializing its data in a constant context. For instance, this isn't very useful: constinit vector<int> v; But this would be more so: constinit vector<int> v(16, 1); // Fill with 16 1's. And the reason we can't do this wouldn't be solved by splitting it into multiple functions. EDIT: Actually, come to think of it, C++20's vector already supports the first example. It's just not used much that way because it's not very helpful. https://godbolt.org/z/avY4M9oMK https://godbolt.org/z/avY4M9oMK

EliRivers 1y ago

To be fair, there's a reason for the pattern with init methods you're describing. Without prejudice on any other reasons, the most common reason for this pattern I've seen is people thinking in languages that basically don't have constructors, yet writing C++. It's not a good reason.

Mond_ 1y ago
How would you deal with fallible construction of objects while avoiding exceptions in idiomatic C++?
- metaltyphoon 1y ago
  This was one of the best decisions that Rust and Go did; not have constructors. In C# this is super annoying too, specially when you need an async operation to construct a type. This is usually done by having an private constructor and then using a static public method to create the type.
  - Conscat 1y ago
    Rust and Go have no form of a conversion operator (even if not a constructor), which makes scripting a type system essentially impossible. Numeric libraries in both of those languages are extremely cumbersome, largely for this reason.
    - tialaramex 1y ago
      I don't understand this comment at all. Rust not only has the 'as' operator for this exact purpose, but it also has the suite of traits From, Into, TryFrom and TryInto for the infallible and fallible conversions respectively.
      - Conscat 1y ago
        As is an infix operator, it can never be invoked implicitly to draw these relationships between different types.

Conscat 1y ago

> the object construction can be done with static methods I've done that a lot too, but I found that free functions are much better for this than static member functions, because you can't get CTAD from static member functions. For example, with constructors we could write: vector{1, 2, 3}; // deduces vector<int> And with a static member, we would need: vector<int>::init(1, 2, 3); With a free function, we could write: make_vector(1, 2, 3); // returns vector<int>

fooker 1y ago

Right, when construction is fallible you need a factory. Constructors are called in surprising places when running a C++ program. For example, think of a copy constructor failing somewhere far away from the code you are writing. If C++ allowed construction to fail, the control flow of propagating these errors would be tedious and invasive. Hence exceptions as the only way to fail in a construction.