4 ms·
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 (a
by cageface 15y ago
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.
- rubashov 15y ago> alloc errors throw 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.
- gnaritas 15y agoMany 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.
- pmjordan 15y agoI 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.
- scott_s 15y agoIn 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.
- cageface 15y agoIf 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?
- scott_s 15y agoYou don't. It will segfault.
- james4k 15y agoIndeed, 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.
- pestaa 15y agoThat 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?
- james4k 15y agoThere is EASTL, though I've never used it myself. https://github.com/paulhodge/EASTL https://github.com/paulhodge/EASTL 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 https://github.com/TTimo/doom3.gpl At the very least, there's a lot of great reference out there.
- ComputerGuru 15y agoNot 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. See here for many solutions: http://stackoverflow.com/questions/553103/can-i-disable-exceptions-in-stl http://stackoverflow.com/questions/553103/can-i-disable-exce...