#12179 closed Bugs (fixed)

Including boost/optional/optional_fwd.hpp without first including boost/config.hpp doesn't compile.

Reported by: c.d.glover@… Owned by: Fernando Cacciola
Milestone: Boost 1.62.0 Component: optional
Version: Boost 1.61.0 Severity: Problem
Keywords: Cc:


This code does not compile;

#include <boost/optional/optional_fwd.hpp>

int main() {

return 0;


It seems this is because optional_fwd.hpp tries to only depend on boost/config/suffix.hpp, but this file itself depends on other config macros that need to be included first.

I have been able to workaround this issue by including boost/config.hpp before optional_fwd.hpp

Attachments (0)

Change History (5)

comment:1 Changed 17 months ago by post@…

Here's a slightly different problem, but with the same solution:

If optional/optional_fwd.hpp is included before any boost header that includes config.hpp (for example optional.hpp), there are multiple problems. Example:

#include "boost/optional/optional_fwd.hpp"
#include "boost/optional.hpp"

int main() {
    return 0;

The first problem is a build failure because of inconsistent defines:

  1. optional/optional_fwd.hpp includes config/suffix.hpp
  2. config/suffix.hpp uses an include guard to prevent multiple inclusions of itself
  3. config/suffix.hpp doesn't define int128_type and uint128_type because BOOST_HAS_INT128 is not defined
  4. another boost header includes config.hpp
  5. config.hpp includes config/compiler/gcc.hpp
  6. config/compiler/gcc.hpp defines BOOST_HAS_INT128
  7. config.hpp includes config/suffix.hpp, but the include guard prevents reevaluation of the file

Now, we have BOOST_HAS_INT128 defined, but boost::int128_type and boost::uint128_type are not. If we now try to compile something that includes type_traits/is_integral.hpp (which optional/optional.hpp indirectly does), we get to this code, which doesn't compile due to unknown types:

#ifdef BOOST_HAS_INT128
template<> struct is_integral<boost::int128_type> : public true_type{};
template<> struct is_integral<boost::uint128_type> : public true_type{};

The second class of problems are redefinition warnings. Here's an example (there are multiple defines that get redefined):

  1. optional/optional_fwd.hpp includes config/suffix.hpp
  2. config/suffix.hpp first sets BOOST_LIKELY to a no-op default
  3. another boost header includes config.hpp
  4. config.hpp includes config/compiler/gcc.hpp
  5. config/compiler/gcc.hpp redefines BOOST_LIKELY to work as intended -> redefinition warning

As a conclusion, optional/optional_fwd.hpp should include config.hpp instead of config/suffix.hpp Currently, optional/optional_fwd.hpp is the only file in boost that includes config/suffix.hpp directly (not through config.hpp), so it's probably not meant to be used this way.

(context: I'm using gcc 5.3.1 on Fedora 23)

comment:2 Changed 17 months ago by post@…

I posted a pull request with the (trivial) fix for this problem on Github:

comment:3 Changed 14 months ago by Tony Lewis <tonyelewis@…>

I think this is related to ticket:12142.

comment:4 Changed 12 months ago by akrzemi1

A related ticket #12142 will be fixed in 1.62.0 release. Hopefully this one will be fixed as well.

comment:5 Changed 12 months ago by akrzemi1

Milestone: To Be DeterminedBoost 1.62.0
Resolution: fixed
Status: newclosed

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Fernando Cacciola.
The resolution will be deleted.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.