Menu
▾
▴
Re: [Spirit-general] [boost] [karma][fusion] Signed integer members of Boost.Fusion adapted ADTs are not output correctly with Boost.Spirit.Karma rules
|
From: Jeroen H. <vex...@gm...> - 2011-12-27 19:14:42
|
Hi, On 27 December 2011 19:24, Torsten Maehne <Tor...@gm...> wrote: > Hello Jeroen, > > thank you for looking on my test case on Boost trunk! Unfortunately, > Boost trunk doesn't seem to be in a good shape currently for my test > case, as it seems to trigger additional unrelated problems. Boost 1.48.0 > seems to be currently a more suitable starting point for a diagnosis of > the original problem. > > Please see my comment below regarding your suggestion. > > Jeroen Habraken wrote: > >> Hi, >> >> On 27 December 2011 00:51, Torsten Maehne <Tor...@gm...> wrote: >>> Hello, >>> >>> I'm using Boost.Spirit.Karma to format the output of some nested structs >>> (direct access of the public member variables) and abstract data types >>> (ADTs) (access to the private member variables via getters and setters) >>> in my code. I'm using Boost.Fusion to adapt the ADTs into a sequence of >>> values of primitive data types for output with Boost.Karma. This worked >>> fine till Boost 1.44. Since Boost 1.45 up till 1.48 and the current >>> Boost trunk (I tested svn revs 75505, 75963, and 76196) the output of unsigned >>> integer members of Boost.Fusion-adapted ADTs doesn't work anymore -- >>> even though I took into account the change in the name of macro from >>> BOOST_FUSION_ADAPT_CLASS to BOOST_FUSION_ADAPT_ADT as well as the >>> additionally required header >>> boost/spirit/include/support_adapt_adt_attributes.hpp. >>> >>> The problem is demonstrated in the attached test case for rational >>> number ADTs and structs, which use signed integer member >>> variables. Compilation of this test case against Boost 1.44.0 will >>> succeed and it will run without any errors. Compilation of this test >>> case against Boost 1.45.0 and 1.46.1 will fail. Compilation against >>> Boost 1.47.0 and 1.48.0 will succeed, but the output of negative values >>> of signed integer members of Boost.Fusion-adapted ADTs will be >>> wrong. The minus sign is output correctly, but it is followed by a wrong >>> value, which seems to be yielded by a cast from a signed to an unsigned >>> integer value instead of taking the absolute value of the signed integer >>> value. This has been observed on Mac OS X 10.7.2 (x86_64) with Xcode 4.2 >>> using Apple's g++ 4.2.1, Apple's clang++ 3.0. Interestingly, compiling >>> the test case against Boost 1.47.0 or Boost 1.48.0 using MacPorts g++ >>> 4.5.3, will yield more output checks to fail for Boost.Fusion-adapted >>> ADTs used in Karma output rules. >>> >>> Compilation against Boost from the Subversion trunk (I tested >>> revs. 75505, 75963, and 76196) does only succeed using Apple's clang++ >>> 3.0 and execution will yield the same wrong output for negative values >>> of signed integer members of Boost.Fusion-adapted ADTs. Compilation >>> fails with Apple's g++ 4.2.1 and MacPorts g++ 4.5.3. >>> >>> I'm not able to locate the root cause for this problem, whether it is in >>> Boost.Fusion or Boost.Spirit.Karma. I would appreciate any help to >>> resolve this annoying issue. Until a solution is found, I'm stuck with >>> Boost 1.44.0. >> >> Several things seem to play a role, but I've had a look at as to why >> the code doesn't compile using boost-trunk and found the cause to be >> an ambiguity: >> >> boost/typeof/native.hpp:30:9: error: reference to 'enable_if' is ambiguous >> boost/utility/enable_if.hpp:36:10: error: candidates are: >> template<class Cond, class T> struct boost::enable_if >> boost/test/tree/decorator.hpp:184:23: error: class >> boost::unit_test::decorator::enable_if >> >> As enable_if is often used without being fully qualified this breaks >> in a major fashion. Since boost/test/tree/decorator.hpp seems to be >> quite new (added 2011-10-02 11:00:16 +0200) it might be best fixed >> there. >> > > On my side, I was not able to reproduce the "enable_if is ambiguous" > error related to Boost.unit_test that you've observed. I tried with > Apple g++ 4.2.1 and MacPorts g++ 4.5.3. Actually, you are. The logs https://svn.boost.org/trac/boost/attachment/ticket/6126/test_signed_integer_output_with_karma_boost_trunk_gcc42.log and https://svn.boost.org/trac/boost/attachment/ticket/6126/test_signed_integer_output_with_karma_boost_trunk_gcc45.log show: /opt/boost-trunk/include/boost/fusion/iterator/equal_to.hpp:77: error: expected nested-name-specifier before ‘enable_if’ /opt/boost-trunk/include/boost/fusion/iterator/equal_to.hpp:77: error: expected initializer before ‘<’ token These occur because the code states "typename enable_if<Cond, T>::type" and the typename doesn't make sense in combination with boost::unit_test::decorator::enable_if. When you remove the typename (which is essentially what I did when debugging) you'll get the ambiguity error. >>> Please note that I also submitted a bug report on this issue more than 6 >>> weeks ago without any reaction so far: >>> >>> <https://svn.boost.org/trac/boost/ticket/6126> > > This ticket contains compile logs of my tests with the two mentioned > compilers. > >>> Best regards, >>> >>> Torsten Maehne >> >> Note: I've included bo...@li... in the discussion. >> > > I hope that someone has an idea how to proceed further to separate the > different problems. My original test case was designed to just expose > the signed integer output problem. I used Boost.unit_test to facilitate > its integration into a test suite. Now it seems to cause further side > effects... at least on your side. > >> Kind regards, >> Jeroen Habraken >> >> _______________________________________________ >> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > > Best regards, > > Torsten Maehne I can't comment on https://svn.boost.org/trac/boost/attachment/ticket/6126/test_signed_integer_output_with_karma_boost148_gcc42_clang3.log, not (yet) sure what's going on there. Jeroen |