4 ms·

> you're not going to be using features that haven't actually been published in a formal standard (optional). So you then have things like: class Foo {

by imron 9y ago

> you're not going to be using features that haven't actually been published in a formal standard (optional). So you then have things like: class Foo { public: static Foo* create(); ... }; ... Foo* foo = Foo::create() if ( foo != nullptr ) ... > so how do you have Containers of foo? std::vector<Foo*> Not saying either of those are better than the alternative (I prefer using exceptions and RAII), just pointing out what I've seen in real world projects.

mikepurvis 9y ago
I don't think this is the proposal. The proposal is that the object contains a genuine constructor that only does the bare-bones "safe" stuff, and then it has a separate non-static method that does the might-fail initialization. So: class Foo { public: Foo(); bool initialize(); // returns success ... }; ... Foo foo; if ( !foo->initialize() ) { // handle error } This also means you can break up your initialization so that you drive the risky pieces from outside the object, rather than monolithically from within. This has a further benefit for testing, since you can use your major objects without fully initializing the entire world that they depend on.
- imron 9y ago
  It was almost the exact proposal specified by my grandparent post except using a pointer rather than an optional. It's also a technique that is widely used. See for example the cocos2d-x game library. The benefit of such a technique is that you can then make the constructor private, making it impossible to create an object and not also call the initialize() method.
  - gpderetta 9y ago
    It is very different from having a static method returning an optional, which guarantees that you can access the optional (with at least an assert in debug mode) only if the object is actually successfully constructed. Using a separate initialize member function means that you may have objects in a zombie state laying around after a failed construction which lead to all kind of initialization order issues (you might get a pointer to the object, but is it initialized?). Also you need to remember to check the return type, which also need to be meaningful (does it return false on failure? or it returns 0 on success?). Two phase initialization is a known antipattern which is, unfortunately, widely used and lead to all kind of pains. Friends do not let friends use 2PI. edit: sorry, I misread your comment, you were referring to the static function returning a pointer, which as you note is almost the same as the optional version. It forces heap allocation though, which is bad.
    - imron 9y ago
      I agree that 2PI leads to all kinds of pain, but what I meant is not 2PI. Here's a more complete example: class Foo { public: static Foo* create() { Foo* result = new Foo(); //exceptions disabled so new can return nullptr if ( result ) { //configure result here } return result; } private: Foo() {} }; ... Foo* badFoo = new Foo(); // compiler error because Foo() is private Foo* foo = Foo::create(); //all good, no 2PI and can't forget to call initialize code if ( foo ) //check for non-null, note, if using an optional you'd also need a similar check { ... } Now the only way to create a Foo object is through the create() function and there is no separated initialize - it all happens in the same place. This pattern of using a static create method is explicitly designed to avoid 2PI and is very common, especially in codebases that disable exceptions. Also note that I'm not personally advocating using it, just that it is commonly used to avoid 2PI.
      - maccard 9y ago
        That still means you can't creat instances of Foo on the stack though, doesn't it? Or you can't have a storage or contiguous Foo's (e.g. vector<Foo>)
        imron 9y ago
        Correct. It means you can't create instances of Foo on the stack (outside of the Foo class). You can have contiguous Foos, but not in a vector. You can either have another static function to return an array of Foos, or more commonly have some sort of pool allocator and have the create function allocate objects from the pool. Anyway, yes, there are limitations for using this pattern, so like all things it's a matter of weighing up the tradeoffs.
    - imron 9y ago
      > It forces heap allocation though, which is bad. It does, and it can be, but in situations where it matters, the static create function typically returns a value from a preallocated pool of memory, so objects are all contiguous and cache friendly.

by imron 9y ago

mikepurvis 9y ago

I don't think this is the proposal. The proposal is that the object contains a genuine constructor that only does the bare-bones "safe" stuff, and then it has a separate non-static method that does the might-fail initialization. So: class Foo { public: Foo(); bool initialize(); // returns success ... }; ... Foo foo; if ( !foo->initialize() ) { // handle error } This also means you can break up your initialization so that you drive the risky pieces from outside the object, rather than monolithically from within. This has a further benefit for testing, since you can use your major objects without fully initializing the entire world that they depend on.

imron 9y ago
It was almost the exact proposal specified by my grandparent post except using a pointer rather than an optional. It's also a technique that is widely used. See for example the cocos2d-x game library. The benefit of such a technique is that you can then make the constructor private, making it impossible to create an object and not also call the initialize() method.
- gpderetta 9y ago
  It is very different from having a static method returning an optional, which guarantees that you can access the optional (with at least an assert in debug mode) only if the object is actually successfully constructed. Using a separate initialize member function means that you may have objects in a zombie state laying around after a failed construction which lead to all kind of initialization order issues (you might get a pointer to the object, but is it initialized?). Also you need to remember to check the return type, which also need to be meaningful (does it return false on failure? or it returns 0 on success?). Two phase initialization is a known antipattern which is, unfortunately, widely used and lead to all kind of pains. Friends do not let friends use 2PI. edit: sorry, I misread your comment, you were referring to the static function returning a pointer, which as you note is almost the same as the optional version. It forces heap allocation though, which is bad.
  - imron 9y ago
    I agree that 2PI leads to all kinds of pain, but what I meant is not 2PI. Here's a more complete example: class Foo { public: static Foo* create() { Foo* result = new Foo(); //exceptions disabled so new can return nullptr if ( result ) { //configure result here } return result; } private: Foo() {} }; ... Foo* badFoo = new Foo(); // compiler error because Foo() is private Foo* foo = Foo::create(); //all good, no 2PI and can't forget to call initialize code if ( foo ) //check for non-null, note, if using an optional you'd also need a similar check { ... } Now the only way to create a Foo object is through the create() function and there is no separated initialize - it all happens in the same place. This pattern of using a static create method is explicitly designed to avoid 2PI and is very common, especially in codebases that disable exceptions. Also note that I'm not personally advocating using it, just that it is commonly used to avoid 2PI.
    - maccard 9y ago
      That still means you can't creat instances of Foo on the stack though, doesn't it? Or you can't have a storage or contiguous Foo's (e.g. vector<Foo>)
      - imron 9y ago
        Correct. It means you can't create instances of Foo on the stack (outside of the Foo class). You can have contiguous Foos, but not in a vector. You can either have another static function to return an array of Foos, or more commonly have some sort of pool allocator and have the create function allocate objects from the pool. Anyway, yes, there are limitations for using this pattern, so like all things it's a matter of weighing up the tradeoffs.
  - imron 9y ago
    > It forces heap allocation though, which is bad. It does, and it can be, but in situations where it matters, the static create function typically returns a value from a preallocated pool of memory, so objects are all contiguous and cache friendly.