[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