Re: [boost] [Spirit-general] [karma][fusion] Signed integer members of Boost.Fusion adapted ADTs are not output correctly with Boost.Spirit.Karma rules

Subject: Re: [boost] [Spirit-general] [karma][fusion] Signed integer members of Boost.Fusion adapted ADTs are not output correctly with Boost.Spirit.Karma rules
From: Jeroen Habraken (vexocide_at_[hidden])
Date: 2011-12-27 07:01:40

Hi,

On 27 December 2011 00:51, Torsten Maehne <Torsten.Maehne_at_[hidden]> 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.

> 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>
>
> Best regards,
>
> Torsten Maehne

Note: I've included boost_at_[hidden] in the discussion.

Kind regards,
Jeroen Habraken