[thehardsphere]

Yeah, I'd like to know why you'd still use C++ at all if you find Orthodox C++ appealing. It would seem easier to just write C. Unless I'm missing something (I probably am; don't write enough of either one to have an informed opinion, which is why I'd love to hear more about this).

[dgfgfdagasdfgfa]

RAII is incredibly attractive, especially if you disable exceptions.

[tjoff]

Why would RAII be especially attractive if disabling exceptions?

[mbel]

Probably because exceptions are the biggest source of pain with RAII.

[tjoff]

I'd say that exceptions are the biggest source of pain if you don't have RAII.

Or, rephrased: RAII is incredibly attractive, especially when exceptions are being used.

[dgfgfdagasdfgfa]

RAII is necessary for exceptions. Why the hell would you do that to yourself?

[leni536]

How do you deal with constructors that might fail?

[adrift]

You don't have constructors that 'fail'.

[ryandrake]

So, allocating memory for objects is not part of construction? Again, why not just stick with C?

[maccard]

If you disable exceptions hoe do you handle failures in constructors?

[dgfgfdagasdfgfa]

I mean it's kind of a smartass answer, but—don't fail during constructors. Move all possible code that can fail into an initialize method; check explicitly for allocation failure and/or put things on the stack instead of heap when possible; consider failing hard with a stack trace or core dump over catching and processing exceptions before (likely) failing anyway.

[dan00]

Instead of using a constructor you can use a constructor method e.g.:

    class Foo {
       public:
          static std::optional<Foo> create();

       private:
          Foo();
    };

[maccard]

In general if you're not using exceptions, you're not going to be using features that haven't actually been published in a formal standard (optional).

This now means that you can't use any constructors, so how do you have Containers of foo?

[imron]

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

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.

[dan00]

My bad, I thought std::optional is part of C++14, it seems to be part of the next standard C++17, but there's still boost::optional.

About the container issue: if you have objects that might fail during the creation it seems like a bad idea to allow things like:

    std::vector<Foo> foos(10);

Having a separate initialization method which might fail - like proposed by others - is another option, but this means your objects need some kind of internal initialization state, and whenever you're handling such an object you never can be absolute sure that it's in a valid state.

I'm quite a big fan of making invalid state not representable in an object and handling failure cases as early as possible.

What the create method returns depends heavily on your use case. If the returned objects can always be allocated on the heap, then a pointer or unique_ptr can be returned.

[ryandrake]

How would you handle failure in copy constructors?

[dan00]

Most likely having an explicit copy method instead of a copy constructor.

[badsectoracula]

Well, you still get classes and templates.

[dbartolini]

Sensible usage of templates, operator overloading and namespaces is ok.