[CLN-list] Overriding read_number_bad_syntax on OS X
Richard B. Kreckel
kreckel at ginac.de
Fri May 18 00:52:39 CEST 2007
Ron Garret wrote:
>> Thanks for these timings. I'm now convinced that it's worth throwing
>> exceptions and dropping support for -fno-exceptions. These worst- case
>> 10% are acceptable.
>
> We're in violent agreement.
Unfortunately, my time is very limited. But I'm planning to transform
the aborting functions one-to-one to throw statement. Much like the
(untested) patch attached does for read_number_bad_syntax,
read_number_eof, and read_number_junk.
Unless someone raises objections, I'll proceed in the same way with
cl_abort, cl_error_division_by_0, cl_as_error, cl_notreached_abort,
uninitialized_ring, uninitialized_error, cl_error_floating_point_nan,
cl_error_floating_point_overflow, cl_error_floating_point_underflow,
cl_ash_error, cl_error_exquo, and maybe others.
I don't think there will be an impressive exception class hierarchy.
Deriving all input exceptions from one common base makes sense, though.
Maybe it would also be useful to derive all CLN exceptions from one
common base, which is in turn derived from std::runtime_error. But that
should be enough, I think.
Ron, the patch should work for your input routines. How does it work for
you? It will take me at least two weeks till I can check in a complete
patch to CVS HEAD (a.k.a. CLN 1.2-pre.)
-richy.
--
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cln-exceptions.patch
Type: text/x-patch
Size: 14656 bytes
Desc: not available
Url : http://www.cebix.net/pipermail/cln-list/attachments/20070518/16943c25/cln-exceptions.bin
More information about the CLN-list
mailing list