Exceptions

[Weeble]

What's the opinion of C++ exceptions over at Moonpod? Useful? Costly? Dangerous?

[Poo Bear]

With VC6/7 there was too great a performance overhead, but with VC8 maybe that is no longer true?

In terms of validating code, i've got used to using assert and verify, I use my own version so it's also platform independent. I know it isn't the same thing as exceptions, but in use you get similar benefits i.e. catching code that has entered an unexpected state. You just have to get into the habit of using them everywhere and thinking about what the expected state of the code should be and the boundary conditions.

--these disappear when I make a release build
MP_ASSERT(x)
MP_MESS_ASSERT( "your message", x )

--these stay even in release builds, useful if you are letting people write add-ons or scripts or you need to test the code running at full speed.
MP_VERIFY(x)
MP_MESS_VERIFY( "your message", x )

--a useful extra tool lets you make the messages dynamic
MP_MESS_VERIFY( MP_CAT( "Error: x=", m_nameStr, " in input" ), 0 )

Functionality wise, when they fire up you get the message, file and line number plus the call stack. You also get the option there and then to ignore the assert this time, break into the debugger or ignore the assert permanently, very useful.

I also override new and delete globally so I can monitor if, when and where things get deleted. There is an app called boundschecker that attempts to do the same thing automatically, but i've found it doesn't always catch everything. The best option is to use both.

[Weeble]

How do you implement MP_CAT without leaking?

I saw a cute way of putting messages into regular assertions:

assert(count<=5 && "There should never be more than 5 doohickeys at once.");

I'm still in two minds about messages in assertions. I often find it easier to express and understand the condition than the message, especially if it's in the middle of an algorithm. It can be messy trying to explain why the condition should hold. When I do have messages I find I prefer "Such and such should have happened" to "Such and such is wrong". The former seems to make it easier to read the code - it's telling you the way things are supposed to be. The latter I find jarring, somehow. I guess I feel that an assertion should be primarily a positive statement about the current state of things, and including an error message in there seems to cloud its meaning for me.

What do you add to the overridden new and delete? Do you store a stack trace with the allocated block? Or do you add parameters to new? Does it matter if DirectX or STL stuff uses them? Do you even use any of the STL?

[Poo Bear]

[Weeble]

I think the reason the STL is so slow in debug is that it gets heavily inlined by the optimizer, and it is designed to take advantage of this. I've found that stepping through operations on a std::vector involves a lot of calls in debug, but barely any in release. std::auto_ptr involves calls for every dereference, but these disappear completely under optimisation and it looks just like a normal pointer.

I'm interested in the overridden new and delete, because something I've had to work with involved overridden new and delete that needed you to call special macros, both before every usage of new, and before and after every call to a library function that might call new itself. While this ensures there is plenty of information for analysing allocation and deallocation patterns, it also often makes it impossible to use initialiser lists or have foreign member objects that allocate their own memory in a constructor, because there's nowhere to fit in the macro calls. I'm sure there must be a better way to achieve the same effect. (I've also discovered that it isn't very thread-friendly, but that's beside the point right now.)

[Poo Bear]

Oh sorry, my language has mislead you, I don't actually override new and delete themselves that causes too many problems with other libraries I meant I use different calls and simply watch what they are doing. Sorry, I confused matters there with bad language choice. I'm only mapping my own memory usage patterns, hence the suggestion you also use something like boundschecker as well (you might even be able to just rely on it completely, I haven't checked the latest version so it may have been improved enough).

I do this when I new something:

#define MPNEW(objClass) (objClass*)MPDebugNew(new objClass, #objClass, sizeof(objClass), __FILE__, __LINE__)
...
...
#define MPNEWP10(objClass, parm1, parm2, parm3, parm4, parm5, parm6, parm7, parm8, parm9, parm10) (objClass*)MPDebugNew(new objClass(parm1, parm2, parm3, parm4, parm5, parm6, parm7, parm8, parm9, parm10), #objClass, sizeof(objClass), __FILE__, __LINE__)

#define MPNEWARRAY(objClass,num) (objClass*)MPDebugNew(new objClass[num], #objClass, sizeof(objClass)*num, __FILE__, __LINE__)


and match it with this on delete:

#define MPDELETE(x) { delete x; MPDebugDelete(x, __FILE__, __LINE__); }

#define MPDELETEARRAY(x) { delete [] x; MPDebugDelete(x, __FILE__, __LINE__); }

So its just calling new/delete as normal, but letting me keep an eye on it.

[SethP]

[Weeble]

I'm pretty sure using # in a macro makes a string literal out of the parameter. So

[SethP]

[Poo Bear]

Weeble has it right, as you're interested here is some more code. It isn't really very portable so it wont be much practical use but might help make things clearer.

Calling this creates the object we are interested in and then calls the tracking code. Notice the "new" in the first parameter.

[Weeble]

Ah, yeah, the new was staring me in the face and somehow I forgot about it. I've seen the allocating extra space and then partitioning it manually strategy more than once. I think people like it because it helps with debugging when looking at raw memory.

[Poo Bear]

This call can be useful if you are using VisualC++

_CrtCheckMemory()

it returns false if the heap is invalid, it inspects every memory block so it is slow, but handy if something appears to be getting corrupt and you can't track it down.

[SethP]

Thank you very much for your reply Poo Bear. That code is very interesting

[Poo Bear]

http://www.gamearchitect.net/Articles/ExceptionsAndErrorCodes.html

This article looks at exceptions in detail and concludes there is a not insignificant peformance and memory overhead. So it still isn't quite time to switch if you're making something performance critical.

[Weeble]

It annoys me that I can't use exception-like syntax with error-code-like behaviour, particularly when every function involved declares exactly which exceptions it throws. If I can type it out as error-codes with the messiness they incur, why can't the compiler do that work for me? Sure, it doesn't work if a function can throw an exception that its direct caller doesn't know about, but in a great many useful circumstances we can know all about all of the exceptions involved.