I know that using exceptions for normal program flow is just absurd, both by paradigm and the performance hit coupled to doing so. So, most people''s solution: limit their use to checking for resources. Well, what about another abnormal situation such as attempting to copy, though a common base class, one derived class onto another, incompatible derived class? I''m making a gl-object hierarchy, and I''m using a Clone() paradigm so that I can make legal copies of derived classes at all levels of derivation, even when using pointers of the base class. Well, say someone tries copying a TSphere* onto a TCube*. I would say this is a legitmate time to throw a EIncompatibleTypes exception. Comments? Questions? Just wanted to see if anyone agreed w/ me before I decided to add this functionality to my system. Thank you for your bandwidth. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Succinct Demos Online~ I am a software engineer who writes poetic code!

Should be no problem. Adding a try block only adds a couple of instructions to program flow, though there usually are a large number of instructions added to the code for the case when an exception does happen. This is why throwing an exception is what takes a long time--a try/catch block that never fires only costs you a couple of instructions per call.

Thank you, stoffel, that was exactly what I was looking for.

Can you accomplish the same thing with an ASSERT?

There should never be a case where your scenario happens...
The Clone method is supposed to return a base pointer to a copy of sub-class. So if it _was a TSphere* before, it''s a TCube* now (stored in a TShape* or what-not).

They shouldn''t be incompatible types; if you''re downcasting it''s an indication that your design still isn''t quite right (though sometimes it''s inevitable). One of the major benefits of sub-classing is the ability to treat all the (sub)cases uniformily. You shouldn''t need to know what the sub-class is, just what you can do to it (like clone() or render())

Magmai Kai Holmlor
- The disgruntled & disillusioned

Funny thing, M, I had written that exact same thing (re: assert) then deleted it, because it sounded like these were going into a library that could be misused by external clients. Yeah, always use assert if it''s appropriate (for debugging your own code), and then fall back to exceptions (for when clients can break your code through misuse).

I looked at the assembly output of a try block in a debug mode VC program: It only adds 2 instructions. a mov (to store information about jumping on an exception, i suppose), and a jmp (to jump over the catch blocks if execution was completed successfully).

Can''t get much better than that


about asserts: I made my own assert macro which throws an exception, and travels up the call stack, figuring out which functions caused the assertion to fail, up until the root of the program.

I find that in my more complex programs, I do not have time to step through code anymore, especially when a debugger isn''t usable (ex: DX full screen mode), or when VC itself is in release mode. Therefore, I find it much more useful to not only know which function failed, in which file and line it was on, but what exactly caused it to fail as well.

Its kind of cool.

===============================================
It''s either ether or the other,
I press my window to the glass,
the glass turns to gas...
I''m going upstairs now, to turn my mind off...
to turn my mind off...

Ahhh, Mag, I didn''t think that through far enough... Good eyes!

I was wondering more about using the exceptions, though, and that was just a quick (and stupid) example off the top of my head.... Good to realize, though.

Mith, you hit it right on the head.
Thanks guys.

assert when you can, throw when you must I guess? =)

OK, so I''m working on my final class project which is taking ~10min. per test run, so I''m surfing a lot in the meantime. I''ve finally gotten around to reading some of the "Deep C++" articles on MSDN that relate to exceptions--there''s 17 parts. Anyway, part 4 digs into the assembly a bit:
http://msdn.microsoft.com/library/default.asp?URL=/library/welcome/dsmsdn/deep061799.htm

It talks a bit about how there''s a table set up for exception types, kinda like a global virtual function table, and how the IPs of the catch handlers are pushed into the table in each function that can throw an exception. So, it''s a little more than 2 instructions (ok, so like 4?), but pretty neat to see.

BTW, the author TOTALLY manhandles MS''s use of "structured exception handling", including some well-deserved harsh criticism of those damn macros.

Just to be totally tangent Why wouldn''t it be the sphere that would inscribe the cube? That was a sharp point Magmai.