6 ms·

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

• badsectoracula 9y ago
  Well, you still get classes and templates.
• dgfgfdagasdfgfa 9y ago
  RAII is incredibly attractive, especially if you disable exceptions.
  • maccard 9y ago
    If you disable exceptions hoe do you handle failures in constructors?
    • dgfgfdagasdfgfa 9y ago
      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 9y ago
      Instead of using a constructor you can use a constructor method e.g.: class Foo { public: static std::optional<Foo> create(); private: Foo(); };
      • maccard 9y ago
        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 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.
  • tjoff 9y ago
    Why would RAII be especially attractive if disabling exceptions?
    • deleted 9y ago
      [deleted]
    • mbel 9y ago
      Probably because exceptions are the biggest source of pain with RAII.
      • tjoff 9y ago
        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 9y ago
          RAII is necessary for exceptions. Why the hell would you do that to yourself?
      • leni536 9y ago
        How do you deal with constructors that might fail?
        • adrift 9y ago
          You don't have constructors that 'fail'.
          • ryandrake 9y ago
            So, allocating memory for objects is not part of construction? Again, why not just stick with C?
            • deleted 9y ago
• dbartolini 9y ago
  Sensible usage of templates, operator overloading and namespaces is ok.