On Aug 9, 2011, at 1:39 AM, Ben Stott wrote: > ... > (depending on how things go), if the RAII graphics lock (fltk::GSave, > currently) is unable to save the graphics state through the inability to > acquire or init. resources, an exception could be thrown to inform the user > that anything that happens from that point in the code is going to hell in a > handbasket.
How does throwing an exception help here - more than likely the app will not be written to catch the exception (you'd need to wrap all drawing in a try/catch block) and in the end you'll just end up with a crashed app and lost data. OTOH, overflowing a matrix stack will just result in some strange drawing, which is visible to the user and developer but allows the user a chance to save their data. > ... > > I see Ben says "They're portable (except perhaps to some really obscure > > embedded systems)" - I guess he means me! > > I'd be surprised if most of these, nowadays, didn't support exceptions. Given > the push towards an attempt at standard-compilance (and even pre-empting the > c++0x standard) by most major compiler vendors, I don't see why embedded > system compilers would be *that* much different.... Doing exceptions properly requires a LOT of overhead in the compiler and runtime, and there exist today threading implementations which are not safe to use with C++ exceptions, and not on obscure platforms, either - throwing an exceptions from a dispatch thread (block) on Mac OS X will do an excellent job of crashing your program, and blocks are literally used *everywhere* in the system libraries now. ________________________________________ Michael Sweet, Easy Software Products
_______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
