Dear John, On Thu, 28 Jul 2005, John Pye wrote:
I've been doing a lot of work with GiNaC recently but just now I think I have a problem which relates more specifically with CLN, so hopefully I'm asking this question in the right place.
I have had a few problems now with CLN's error handling: it tends to just abort when something goes wrong. Is there a reason why it doesn't just throw exceptions that I can catch?
void cl_error_floating_point_nan (void) { fprint(std::cerr, "floating point NaN occurred.\n"); cl_abort(); }
I can see that I could rewrite the 'cl_abort' function so that it does throw exceptions, but I just wanted to point out that CLN is a big job to compile and it might be nice if it gives this sort of functionality out-of-the-box.
I've also become somewhat unsatisfied with that scheme, lately. But I haven't found the time to dig into this. Question: What exactly happens when you throw an exception from within a library that was compiled with -fno-exceptions?
I can't use the suggested method from the manual either, [...] because my pre-compiled CLN doesn't seem to have debug symbols:
Of course not: when I last compiled it with -g the size of the library exceeded 64MB. I'm not enthusiastic about shipping precompiled lib of this size.
So, I'd like to suggest replacing cl_abort with either a SIGFPE or a standard exception of some sort.
I don't see how SIGFPE would help you with the "no stack" problem. And before compiling it with exceptions I would be interested in the overhead this incurs, especially in the stack unwinding code that comes with dtors.
But please, if there are other issues at hand, or reasons why you don't do things that way, I'd be keen to know.
The list of reasons above is complete, I think. Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>