Re: [Boost-users] [spirit] real_p fails on negative exponent

Subject: Re: [Boost-users] [spirit] real_p fails on negative exponent
From: Joel de Guzman (joel_at_[hidden])
Date: 2008-12-11 07:23:43

Jan Boehme wrote:
> Hi Joel,
> 
> On Tue, Dec 9, 2008 at 12:55 AM, Joel de Guzman
> <joel_at_[hidden]> wrote:
>> Jan Boehme wrote:
>>> Hi Joel,
>>>
>>> On Mon, Dec 8, 2008 at 2:07 PM, Joel de Guzman wrote:
>>>> Jan Boehme wrote:
>>>>> Hi,
>>>>>
>>>>> on my system (RHEL3, libc 2.3.2, gcc 3.2.3, Intel 10.1 which is used to
>>>>> compile and link) real_p fails to parse real numbers like 1.0E-001 and it is
>>>>> most likely the negative exponent as 1.0E001 works as expected.
>>>>> Our investigations brought us to numerics.hpp line 162 where the int
>>>>> parser which is used by real_p is declared as 'int_parser<T, 10, 1, -1>'
>>>>> with T=double. I don't see the reason for this yet and
>>>>> the 'out of the box' int parser 'int_p' itself is declared using
>>>>> 'int_parser<int>'.
>>>>>
>>>>> Here my questions:
>>>>> Do I have to expect any problems using int instead double for the real_p
>>>>> exp_n parser?
>>>>> Is this a kind of a mistake as even int_p is declared using 'int'?
>>>> Please post a minimal test case. I'd venture a guess that the problem
>>>> is elsewhere. We do have real_p tests with negative exponents. And
>>>> all is fine, as expected. I did test your case and it works fine:
>>>>
>>>> added this in numeric_tests.cpp:
>>>>
>>>>   BOOST_TEST(parse("1.0E-001", real_p).full); //  Good.
>>> please have a look on my system specs. Maybe I should say that I haven't
>>> any problems using a modern c++ compiler like gcc 4.2.4 plus intel 10.1.
>>>
>>> You did provide a minimal test case yourself: this test runs fail on my
>>> system using boost 1.37 and only my 'workaround' let this rule run
>>> successfully on this machine. It consumes all chars including 'E' and
>>> then '-' doesn't match. Did you try it on a gcc3.2.x too?
>> I've been using 3.2 until last month. All of Spirit's tests are running
>> fine. I'll take another look.
>>
>> BTW, int_parser<double> is perfectly fine.
> 
> if that's perfectly fine why the standard int parser isn't
> parametrized using double?

Why should it? T==int is all the int parser needs. Depending
on your needs, you can use T==double if you want, or a big_int,
if you will. It's just that the real parser uses its T type
(which defaults to double) for the exponent.

> The problem isn't a gcc issue. I compiled your sample using icpc
> previously and checked the plain gcc 3.2.3 now which did a nice job.
> After that I installed a couple of Intel c++ compilers for Linux and
> the test did fail on each of them. I would like confront the Intel
> support with this issue if you encourage me to do so.

I think it's best to first isolate the problem into some
minimal code not using spirit. That means pinpointing what
the real problem is. You gave a hint that the '-' doesn't
match. That part of the code is actually very simple and can
be isolated into a test code. Stepping through the code in
the debugger should reveal the problem.

Alas, I do not have the intel compiler :(

Best,
-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net