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

Subject: Re: [Boost-users] [spirit] real_p fails on negative exponent
From: Jan Boehme (jan.boehme_at_[hidden])
Date: 2008-12-11 05:24:01

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?

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.
Regards, Jan.