   RAII, pointers and exceptions... a rarity?
  Does anyone else use smart pointers (CComPtr for holding DirectX resources and shared_ptr for memory resources)?  What about RAII patterns for lock/unlock of buffers/textures etc.?  Exceptions rather than returning error codes? (if you use RAII and shared pointers, you can safely use exceptions knowing your resources will be released without you having to do anything!).I'm not being funny or anything but I'm a software developer for a living and while I've been researching how to implement the techniques I need for my current project I've seen a lot of *very* dodgy code in these respects.I suppose a lot of articles are put together and posted online with clarity in mind, so perhaps the added complication of teaching good practice might not be possible in the space/time available?  So, do you use them in your production code?  When I first started out as a developer after University I must confess I didn't - but that was 10 years ago and things have moved on a long way since then ;).Just sharing some thoughts.....   
  I work in console game development and these things are indeed a rarity.  About the only thing I see consistently used is RAII for critical sections.   ;Quote:Original post by NypyrenI work in console game development and these things are indeed a rarity.  About the only thing I see consistently used is RAII for critical sections.Ditto. A combination of bad exception support and the general high cost of exception-safe code means that most code I encounter is of the "C with classes" approach rather than 'proper' C++. RAII is great but tends to be only used in critical cases (thread mutexes) rather than general cases (memory allocation etc.).Correct exception-safe C++ is very tricky, and IMHO it's almost always easier to disable exceptions and mandate everything should be communicated via C-style return codes. Yes, this is 'less clean' than proper exception-safe RAII but practically I find it tends to yeild more reliable results.   ;  I've read this about exceptions quite a lot: that they're expensive.  Is this just a hang-over from when every asm instruction a C compiler generated was gone over with a fine tooth comb?  As far as I know, exceptions are only expensive when they're thrown - they only take a few instructions to set up.  Obviously you wouldn't want to be using them in inner loops etc but these kind of things tend to be hand-optimised only after a profiling session.So, is it safe to say that "exceptions are expensive" is a bit of a myth?  On the subject of return codes, I've seen some really amazing coding contortions making sure they're dealt with properly (!).;Quote:Original post by BurnhardI've read this about exceptions quite a lot: that they're expensive.  Is this just a hang-over from when every asm instruction a C compiler generated was gone over with a fine tooth comb?  As far as I know, exceptions are only expensive when they're thrown - they only take a few instructions to set up.  Obviously you wouldn't want to be using them in inner loops etc but these kind of things tend to be hand-optimised only after a profiling session.So, is it safe to say that "exceptions are expensive" is a bit of a myth?  On the subject of return codes, I've seen some really amazing coding contortions making sure they're dealt with properly (!).Exceptions are turned off in console projects because:- The hardware and software does not change, so the theory is that all errors should already be fixed by the time the game ships (or you will fail first-party submission to Nintendo/Sony/Microsoft).  Console programmers liberally sprinkle 'asserts' through the code to help find problems during development - the asserts are removed from the shipped executables.- All current consoles use 32-bit RISC instruction sets.  These bloat code size by about 3x compared to x86.  When your entire game has to fit within a 9 megabyte budget, the 'minor overhead' from exception handling is no longer minor.- Sad to say, but a significant number of C/C++ game programmers I've worked with simply don't know what exceptions are good for at all.For a shipped title, I'm OK with lack of exceptions.  However, during production, I have seen DAYS wasted PER BUG that could have been prevented by helpful exception handling and informative messages.On console projects, the programmers have become so used to avoiding exceptions that they don't even bother using it for the tools that run on the PC!  Tool-chain error handling can make a huge impact on how much time (months!) the content team wastes trying to figure out why almost each separate bit of content they add doesn't work right the first time.   ;  For stuff I do at home I use smart pointers and exceptions. I think it helps me write cleaner code, and more quickly. At work I'm in console-land, so no exceptions. However we do have an "error" type that's a bit nicer than just returning an int as an error code (for instance, it asserts if it's not returned or otherwise handled). We also have various RAII utility classes, but we don't really use them for memory management. For the most part memory allocation is kept explicit.   ;  At work we're starting to use smart pointers and RAII, but it's been a bit of a battle against the old guard to get these techniques in use. Exceptions are never ever used like Nypyren says.At home I use exceptions only in my unit tests, because they're a convenient way to abort back to a certain stack level. If I was using another language like C# or Java, then I'd probably make use of them.Writing exception-safe C++ code isn't as simple as just having RAII everywhere though - your objects can still be left in an inconsistent state without care. Consider:void Widget::Swap( Widget& other ){  member1.swap( other.member1 );  member2.swap( other.member2 );//throws...  member3.swap( other.member3 );};Quote:Original post by BurnhardI've read this about exceptions quite a lot: that they're expensive.  Is this just a hang-over from when every asm instruction a C compiler generated was gone over with a fine tooth comb?  As far as I know, exceptions are only expensive when they're thrown - they only take a few instructions to set up.  Obviously you wouldn't want to be using them in inner loops etc but these kind of things tend to be hand-optimised only after a profiling session.Actual runtime cost varies greatly depending on platform and compiler. On Win32 the overhead while just running code is very minimal, but on some there's a non-trivial amount of setup/teardown around every function call for stack unwinding.Althought when I said "high cost" I don't just mean runtime speed, I'm also refering to cost of writing code that uses them and cost of maintaining proper exception safe code.  (As Hodgman points out, just using RAII everywhere isn't always enough).   ;Writing exception-safe C++ code isn't as simple as just having RAII everywhere though - your objects can still be left in an inconsistent state without care. Consider:void Widget::Swap( Widget& other ){  member1.swap( other.member1 );  member2.swap( other.member2 );//throws...  member3.swap( other.member3 );}In this example, if you use return codes instead of exceptions, you still get an inconsistent state.It doesn't matter what method you use. If you don't handle the errors, it won't work.;  I think using exceptions and RAII rather than return codes can reduce the cyclometric complexity of your functions considerably; at least that's my experience.  It's good on the eyes and the clearly defined behavior is great for maintenance coders too.  Overall I think it's quite public spirited ;).I was browsing some Microsoft code (the source for the dxviewer.exe utility) and was amazed at some of the hoops the programmers were jumping through to *avoid* using exceptions and RAII.  It seems to me that the effort not to use it is far greater than that required to use it.For example, if you look at the Effect9.cpp file, the FromD3DXEffect function has a VB style "goto LFail" in order to delete an allocated pointer if a return code is bad.  If the intervening code is guaranteed not to throw then I suppose it's ok (but it still makes my eyes bleed to look at). If an exception is thrown, the memory won't be released though (!).  All he needed to write was:    shared_ptr<Effect9> pNew(new Effect9())and he wouldn't have needed any goto's at all.  I'm not a purist about this stuff, but I would get bent over the desk and rogered with a telegraph pole if anything like this was discovered in my code during a review.For locking/unlocking vertex buffers and textures, I can write something like this:/*Lock the surface.*/RECT area = {0, static_cast<LONG>(top), static_cast<LONG>(MyMapSize), static_cast<LONG>(bottom + 1) };SurfaceLock surface(MyLuminanceMap, 0, &area, 0);DWORD32 *p = static_cast<DWORD32 *>(surface.LockedArea().pBits);With the SurfaceLock object managing unlocking in its destructor, I am certain the surface gets unlocked when "surface" drops out of scope, so I don't need to explicitly do it and know it'll even happen if an exception is thrown.I suppose the point is that if you throw at all something major has gone wrong so you might as well terminate the program.  Sometimes that's better than letting the program limp on with some component part of it having trouble.  But even so, I like the code clarity of these concepts just as much as the resource cleanup/release facilities.