Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#8772 closed Bugs (fixed)

boost.variant broken in combination with g++ 4.6.x series and C++0x

Reported by: anonymous Owned by: Antony Polukhin
Milestone: Boost 1.55.0 Component: variant
Version: Boost 1.54.0 Severity: Regression
Keywords: signals2 gcc 4.6.x Cc: antoshkka@…

Description

We observed compilation errors in case the main header of boost.signals2 has been included.

Example code :

#include <boost/signals2.hpp>

int main() { return 0; }

The following call fails with errors

g++-4.6.3 --std=c++0x main.cpp -I /opt/boost_1_54_0/

The error message points to some sections in boost.variant recently modified for boost 1.54.0 (I attached the rather lengthly error message).

In case c++0x is not activated or a 4.7/4.8-series version is used, the compilation succeeds.

We simply excluded the problematic section in file boost/variant/variant.hpp which resolved our compilation problem.

I saw that the gcc 4.6 series is not in the list of compilers tested with C++11 enabled but for us this section in variant is the first that fails in case the preprocessor macro BOOST_NO_CXX11_RVALUE_REFERENCES is not set.

Attachments (2)

errormessage.txt (29.6 KB ) - added by anonymous 9 years ago.
The error message generated by g++ 4.6.3
boost_1_54_0_variant.patch (743 bytes ) - added by anonymous 9 years ago.
Simple fix to disable specific variant optimizations relying on rvalue references.

Download all attachments as: .zip

Change History (10)

by anonymous, 9 years ago

Attachment: errormessage.txt added

The error message generated by g++ 4.6.3

by anonymous, 9 years ago

Attachment: boost_1_54_0_variant.patch added

Simple fix to disable specific variant optimizations relying on rvalue references.

comment:1 by Antony Polukhin, 9 years ago

This can be fixed by removing typename B1, from first void assign_impl, making it look like:

        template <typename RhsT, typename B2>
        void assign_impl(
              RhsT& rhs_content
            , mpl::true_ // has_nothrow_copy
            , mpl::false_ // is_nothrow_move_constructible
            , B2 // has_fallback_type
            )

comment:2 by Antony Polukhin, 9 years ago

Cc: antoshkka@… added

comment:3 by anonymous, 9 years ago

Agreed, looks better. I didn't see the obvious ...

For me this bug can be closed after applying this patch to the trunk.

comment:4 by Antony Polukhin, 9 years ago

(In [85080]) Fix compilation of Boost.Variants move assignment for situations when one of the variant template classes has nothrow copy constructor and throwing move constructor (refs #8772)

comment:5 by Antony Polukhin, 9 years ago

Owner: changed from ebf to Antony Polukhin
Status: newassigned

comment:6 by Antony Polukhin, 9 years ago

(In [85087]) Fix test case (refs #8772)

comment:7 by Antony Polukhin, 9 years ago

Resolution: fixed
Status: assignedclosed

(In [85157]) Merge from trunk:

  • make the library work on exception-disabled environments (fixes #8717)
  • fix compilation of Boost.Variants move assignment for situations when one of the variant template classes has nothrow copy constructor and throwing move constructor (fixes #8772)
  • mark move constructor of variant with BOOST_NOEXCEPT_IF (refs #7911)

comment:8 by Antony Polukhin, 9 years ago

Milestone: To Be DeterminedBoost 1.55.0
Note: See TracTickets for help on using tickets.