
Jan Boehme wrote:
Hi Joel,
On Tue, Dec 9, 2008 at 12:55 AM, Joel de Guzman
wrote: Jan Boehme wrote:
Hi Joel,
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
' 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.
On Mon, Dec 8, 2008 at 2:07 PM, Joel de Guzman wrote: 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