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

Richard B. Kreckel kreckel at ginac.de
Tue Oct 1 19:49:01 CEST 2002


On Tue, 1 Oct 2002, Roberto Bagnara wrote:
> 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?

No, -fno-excpetions does not affect class numeric.  Actually, the cleanest
way would be if the routines you mention would do the checking and throw
if they encounter garbage.  I see that they don't do that completely and I
would consider this a bug.  You can trigger things, if you try hard
enough.  Patches for numeric::numeric(const char *) are very welcome but
doing the checks outside is ugly IMO and shouldn't be needed.

But why is this a problem?  Are you writing a frontend parser that must
be totally foolproof or what?

> And, since you are also the CLN maintainer, wouldn't be possible/easy
> to provide a --enable-exceptions configuration option to CLN?

Possibly it would be possible and easy but at the cost of speed.  See
below...

> At a first sight it seems that the modular design of CLN would make this
> task not very difficult.

The modular design is of little help here, since the ctors and dtors are
all over the place and enabling exceptions at one place is certainly not
possible.  It would have the full impact.

>                           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: ...").

That would have to be compiled in, maybe using preprocessor switches, of
course!  I have no plans or resources for doing so, currently, tough I
consider the idea worth following.

It would really be good to carefully measure the impact of enabled
exceptions with recent versions of GCC by running some benchmarks.  I
understand that there was some progress with respect to GCC-2.x though I
don't know how much.

Why not ask an expert?!

Gaby, can you point us to any benchmarks or guesstimates that would be
helpful for getting a picture of the real difference?

Regards
    -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel at GiNaC.DE>
<http://www.ginac.de/~kreckel/>




More information about the PURRS-devel mailing list