The thing is, if you use the subset of C++ people usually recommend, you're hardly better off than with C. Turning off exceptions means you can't use the STL (alloc errors throw) and you can't do any non-trivial work in your constructor so you have to manually initialize everything anyway.
Not true. Many STL distributions have a compile-time flag you can set to disable all exceptions. Otherwise, there are entire STL distributions you can compile against that are exception free.
I wouldn't go so far as to actually turn of exceptions at the compiler level. I just see no need to use them in my own code. And as for failing STL allocations: a lot of the time you realistically can't recover anyway, and where you can and want to, well, you'll have to suck it up and put a try/catch block in there. The world isn't going to suddenly end.
In C++, allocation errors don't need to throw an exception.
Object* obj = new (nothrow) Object;
If the above allocation fails, obj will have the value NULL. It's tedious, but you could replace the default, throwing allocation with a non-throwing allocation in all places of the STL. However, various parts of the STL throw other kinds of exceptions. But, I think one could have a compromise, where you deal with exceptions from libraries you use, but you don't throw any yourself, instead using C-style error handling.
If you replace the STL allocator with a non-throwing allocator how do you know that that vector you just push_back'd didn't actually allocate any new memory?
Indeed, you have to roll your own data structures. This is pretty common in the game development world, where exceptions are considered to have unpredictable performance characteristics.
That is a pretty tight requirement, considering the internals of Ogre 3D engine. It is full with exception classes (some might argue it is way too overengineered.)
Are custom data structures available as open source that don't use exceptions? Or perhaps can you please name an engine that already has this?
Valve's Source SDK makes extensive use of their own data structures, however it is very specialized. For example, linked lists are allocated as growing, contiguous blocks of memory to reduce cache misses. The Doom3 source code might be worth looking at, but I'm sure it's the same story. https://github.com/TTimo/doom3.gpl
At the very least, there's a lot of great reference out there.
Which usually aren't really recoverable anyway. I mean, you can also blow the stack. Then what? Just ignore those essentially unrecoverable eventualities and terminate.
Many would say doing non trivial work in the constructor is bad practice anyway. Constructors should be simple, set instance vars, and be done; all necessary state should be passed in. The objects job is to be what it is, not be its own factory. Construction of complex objects is better left to factory methods, factories, or builders.
