> Ah, thanks. I was using exception to verify my code. Now should I enable them
> for fltk3, or should I remove the try-catch-throw?
I don't know about others, but I'm all for using them. I've always hated having
to check function return values and memory blocks and whatnot to make sure
variables look sane - I'd far prefer to catch, say, std::bad_alloc or an
exception thrown from a function than make sure to remember which functions can
return what error values.
In terms of speed trade-offs, though, I suppose this could potentially kill the
'F' on FLTK; throwing exceptions becomes relatively expensive if it's done
often enough. OTOH, if we have to call function foo() 100 times, checking the
return values will probably sum up to the same time waste as a thrown
exception, assuming the stack isn't *that* deep.
I suppose it depends on what FLTK3 is being pitched as - and how much the
slightly-larger-binary and potentially-slightly-slower binary worries us as a
developer group. It also matters how much it worries the user group, but being
fltk-dev I won't address that!
My vote would be +1 for exceptions, though. If things could break if function
foo() is unable to do exactly what it's supposed to do, exceptions are a great
way of working dealing with this. They're portable (except perhaps to some
really obscure embedded systems) and help clean up code.
Does anyone else have thoughts on this matter?
Ben
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
