9 ms·
Interesting! I'd be interested in better understanding the motivation behind Orthodox C++. In particular, you seem to dump most of the C++ standard library: "D
by comstock 9y ago
Interesting! I'd be interested in better understanding the motivation behind Orthodox C++. In particular, you seem to dump most of the C++ standard library:
"Don't use anything from STL that allocates memory, unless you don't care about memory management."
I now mostly avoid templatization in my own code unless there's a really good reason. But the standard library often lets me avoid explicit memory allocation. Would love to hear more about the motivation for this (and other aspects of your C++ usage).
Also, if you have a demo of the engine in use that would be fun to see!
- thehardsphere 9y agoYeah, 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).
- badsectoracula 9y agoWell, you still get classes and templates.
- dgfgfdagasdfgfa 9y agoRAII is incredibly attractive, especially if you disable exceptions.
- maccard 9y agoIf you disable exceptions hoe do you handle failures in constructors?
- dgfgfdagasdfgfa 9y agoI 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 agoInstead of using a constructor you can use a constructor method e.g.: class Foo { public: static std::optional<Foo> create(); private: Foo(); };
- maccard 9y agoIn 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 agoI 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 agoIt 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 agoWhy would RAII be especially attractive if disabling exceptions?
- deleted 9y ago[deleted]
- mbel 9y agoProbably because exceptions are the biggest source of pain with RAII.
- tjoff 9y agoI'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 agoRAII is necessary for exceptions. Why the hell would you do that to yourself?
- leni536 9y agoHow do you deal with constructors that might fail?
- dbartolini 9y agoSensible usage of templates, operator overloading and namespaces is ok.
- dbartolini 9y agoI do not use STL because I want consistent implementation across all supported platforms. Also, you have to care about memory management when you need performance or when working with memory constrained devices. The way STL deals with custom allocators makes no sense to me, hence my own implementation. You can find demos in the `samples` folder. :)
- moomin 9y agoShow me a man who thinks STL allocators make complete sense, and I'll show you a man with some serious cognitive issues.
- badsectoracula 9y agoGenerally speaking many C++ game engines avoid the STL stuff and reimplement their own more predictable containers, often with custom allocation schemes. The engine at the last game company i worked at, for example, had its own containers and memory allocator and allowed you to define the allocation category and pool per allocator and per object class (so, e.g., dynamic strings would be isolated to their own pool to avoid fragmenting the heap). Related, Andrei Alexandrescu had a great talk about allocators in C++ a couple of years ago: https://www.youtube.com/watch?v=LIb3L4vKZ7U https://www.youtube.com/watch?v=LIb3L4vKZ7U Also related to the Orthodox C++, the same engine also ousted exceptions and RTTI. I'm not sure about the reason for exceptions, but C++'s RTTI was simply inadequate and instead it was replaced with a custom one made using macros (similarly to wxWidgets and MFC) that allowed automatic object serialization and reflection which was used for all saving and loading, exposing objects to the editor automatically with a common UI and exposing classes and objects to the (custom) scripting language with very little setup. Interestingly most of the stuff the engine had to reinvent seem to be first class citizens in the D language. Also Andrei's allocators also seem to be available (experimentally) there too. Personally i prefer plain old C (C89 even, although with a few commonly available or easily reproducible extras like stdint) because i see C++ as too complex for what it is worth. However D seems to provide more power with less complexity and more and more makes me want to try it, especially the new "better C" mode that DMD has got (which i think is somewhat the D equivalent to Orthodox C++ that is linked from the page).
- netheril96 9y ago> dynamic strings would be isolated to their own pool to avoid fragmenting the heap Strings have arbitrary sizes. How does pooling them together reduce fragmentation? Do they always come and go in groups?
- moomin 9y agoI think it reduces fragmentation in the other pools, not the string pool.
- 9y ago
- dagw 9y agoWould love to hear more about the motivation for this (and other aspects of your C++ usage). I know EA wrote their own implementation of STL[1] to get around the problems that the standard implementation was causing in their game engines. Doing a 'diff' between that and a standard implementation should highlight some of the potential problems they found. [1] https://github.com/electronicarts/EASTL https://github.com/electronicarts/EASTL
- torrent-of-ions 9y agoWhat is "a standard implementation"?