Hello Jeroen, On Thu, 29 Dec 2011 00:36:28 +0100, Jeroen Habraken wrote:
Hi,
On 28 December 2011 15:38, Torsten Maehne <Torsten.Maehne@gmx.de> wrote:
Hello Jeroen,
Jeroen Habraken <vexocide@gmail.com> writes:
Hi,
On 27 December 2011 19:24, Torsten Maehne <Torsten.Maehne@gmx.de> 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 <Torsten.Maehne@gmx.de> 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.
Thanks for these explanations. Indeed this issue is distinct from my original problem and maybe should be assigned an own Trac ticket.
Yes, please do.
For your information, I just created Boost trac ticket #6331 to report the conflict between template<class Cond, class T> struct boost::enable_if and class boost::unit_test::decorator::enable_if. I hope that it gets soon picked up by the Boost.Test authors.
Please note that I also submitted a bug report on this issue more than 6 weeks ago without any reaction so far:
This ticket contains compile logs of my tests with the two mentioned compilers.
Best regards,
Torsten Maehne
Note: I've included boost@lists.boost.org 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 <snip/>
Best regards, Torsten