> I think it stems from my background in asm and embedded; I'd much rather
> be "sure" the core was right, than depend on a mechanism to clean up my
> mistakes after the fact... And of course many embedded systems don't (or
> at least didn't, times change, things move on...) support exceptions
> anyway.
On the contrary, you can have a completely bug-free FLTK3 that works absolutely
perfectly (okay, so let's talk hypothetically for a minute ;-)) and on the host
that it's being compiled and run on, there doesn't exist enough RAM for the
user to allocate x amount of widgets. Of course, the user (most likely not
realising this) promptly allocates x+1 widgets and both internal and external
FLTK behaviour starts going all over the place. With exceptions enabled, FLTK
could catch {} std::bad_alloc for the things we allocated and thus fail
gracefully or give the user an error message before quitting. From a FLTK2 (and
potentially 3) standpoint (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.
None of these are strictly mistakes, per se, as they're nothing FLTK really has
control over (well, aside from returning all sorts of strange values). Of
course, Matthias' current use for them is completely different to this
discussion - "testing" code can always be surrounded by some form of #ifdef
DEBUG.....
> 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....
Though that argument is for another day!
Ben
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
