What should I do if boost: tr1 conflicts with std: tr1?

Recently I used the boost: math Library and found that it would conflict with my previous programs. For example, if my program uses

# Include <tr1/unordered_map> and so on. std: something in the tr1 Name field...

Google, the reason is that boost: tr1 was designed to allow you to still use std :: tr1: unordered_map, std: tr1: tuple, etc. Of course, this is a work around und, that is, you actually still use boost: tuple, etc.

You can only write std: tr1: tuple when writing your code.

For example, the implementation of a distribution function in the boost math Library

/Usr/include/boost/math/special_functions/detail/Igamma_inverse.hpp

In the file's 13th rows

# Include <boost/tr1/tuple. hpp>

Then, tuple is used as follows:

Std: tr1: tuple <T, T, T> operator () (const T & x) const // actually, it still uses boost: The following tuple

Check/usr/include/Boost/tr1/tuple. hpp

namespace std{ namespace tr1{ using ::boost::fusion::tuple; // [6.1.3.2] Tuple creation functionsusing ::boost::fusion::ignore;using ::boost::fusion::make_tuple;using ::boost::fusion::tie;using ::boost::fusion::get; // [6.1.3.3] Tuple helper classesusing ::boost::fusion::tuple_size;using ::boost::fusion::tuple_element; }}

This is the work around und method.

Now the problem arises. My GCC already has the implementation of std: tr1, for example, <tr1/unordered_map>, which will bring about a name conflict, for example, two tuple definitions at the same time .... Boost: fusion: tuple and native std: tr1: tuple.

See the boost: tr1 documentation.

Implementation

If Boost. TR1 is configured to use the native TR1 implementation in your standard library, it does not need to do much: It just includes the appropriate header file.

If Boost. TR1 uses the Boost implementation of a component, it needs to contain the appropriate Boost header file and import the required namenamespace std::tr1Medium. Note that only the Declaration as a standard part will be imported: This implementation intentionally and strictly does not introduce all Boost-specific extensionsnamespace std::tr1To capture any portability errors in your code. If you really need to use Boost-specific extensions, you should directly include the Boost header file, then usenamespace boost::. Note that the style of this implementation is not fully compliant with the standard, and it cannot add the template of the custom TR1 componentnamespace std::tr1. One or two other Boost libraries are not fully compliant with the standard, and any inconsistencies are described in the "TR1 category" section. Fortunately, these noncompliant behaviors are rarely used in practice.

If you use a standard header file to includeboost/tr1/tr1, These header file names may sometimes conflict with the existing standard library header files (for exampleshared_ptrAdded to the existing standard library header file<memory>Instead of its own header file ).You can use either of the following methods to forward these headers to the existing standard library header files: For gcc, use#include_nextAnd use macros for other compilers.BOOST_TR1_STD_HEADER(header)(Defined in boost/tr1/detail/config. hpp), it will expand#include <../include/header>. For most compilers, this can be used directly, but this means that these header files cannot be placed in the directory named "include" and already in your compiler search path.

How to solve the conflict problem is still not completely understood, but the solution is still google .. OK .. Later.

It is reasonable to follow the instructions in boost/tr1/tuple. hpp

#ifdef BOOST_HAS_TR1_TUPLE#  ifdef BOOST_HAS_INCLUDE_NEXT#     include_next BOOST_TR1_HEADER(tuple)#  else#     include <boost/tr1/detail/config_all.hpp>#     include BOOST_TR1_STD_HEADER(BOOST_TR1_PATH(tuple))#  endif

I should add a # define BOOST_HAS_tR1_TUPLE to solve the problem, because BOOST_TR1_HEADER (tuple) will be converted# Include <tr1/tuple>

However, the experiment fails ....

Usr/include/boost/tr1/tuple. hpp: 13: 43: error: no include path in which to search for tr1/tuple // WHY knows WHY to Help Me. Thank you ~

// Probably the reason for incude_next? I'm not so careful about the role of include_next TODO.

Finally, google's solution is:

# Define BOOST_HAS_TR1_TUPLE 1 # include <boost/tr1/detail/config. hpp> # undef BOOST_HAS_INCLUDE_NEXT // It seems that incude_next needs to be blocked

Okay, now it's time for peace. I hope anyone who will encounter this problem will save some time :)

About include_next