> 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 fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev