[PURRS-devel] Re: Behavior of numeric::to_int() and numeric::to_long()

Roberto Bagnara bagnara at cs.unipr.it
Tue Oct 1 19:22:08 CEST 2002


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 debugging
>>much 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

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara at cs.unipr.it




More information about the GiNaC-list mailing list