Richard B. Kreckel wrote:
On Tue, 1 Oct 2002, Roberto Bagnara wrote:
What I am saying is that, instead of writing "Not a 32-bit integer..." and exiting, you could throw an exception. This would not impede performance, since the test now controlling the printing would then control the throw.
Unfortunately this is not true since it would prohibit compilation of CLN with the option -fno-exceptions. CLN is designed in such a way that ranges must be checked before the calls are made for reasons of efficiency. Apart from having a register less maybe, the problematic part is the dtors' overhead needed for stack unwinding.
The change I am proposing would make debuggingmuch easier and would make possible recovering from the error (and this is the thing that is very important to us).
You'll have to check yourself at those places where an over/underflow may happen for numeric::to_int() and numeric::to_long(), I'm afraid. The other such checks you were proposing will be applied to CVS in some minutes, though.
OK. Let me see if I understand correctly: this design goal of CLN concerning compilation with -fno-exceptions also affects
numeric::numeric(const char *)
and
const numeric & operator=(const char *s).
If something goes wrong they just print "Illegal number syntax" and exit so that, if we want robustness, we ought to do our own syntax checking before calling them. Is this right?
And, since you are also the CLN maintainer, wouldn't be possible/easy to provide a --enable-exceptions configuration option to CLN? At a first sight it seems that the modular design of CLN would make this task not very difficult. In a first version, when --enable-exceptions, fprint() should not print and cl_abort() should throw an exception instead of exiting. This would constitute a rough approximation but a definite improvement over the current state. Later, one could modify, e.g., read_number_bad_syntax() so as to throw, say, std::invalid_argument("Illegal number syntax: ..."). Just an idea. All the best
Roberto