[TR1/Fusion] Conflict between TR1 and Fusion headers

Hi, I've got a project that uses Boost.TR1 (by adding boost/tr1/tr1 to my include path) and Fusion, and i've run into some errors when including the Fusion headers. For example: boost/fusion/tuple/make_tuple.hpp(21) : error C2027: use of undefined type 'boost::fusion::tuple<>' boost/fusion/iterator/prior.hpp(50) : error C2039: 'tag_of' : is not a member of 'boost::fusion::detail' This seems to be caused by the inclusion of <utility> in <boost/fusion/support/tag_of.hpp>, which when using Boost.TR1 like this causes the Fusion headers to be included again. At the point when <utility> is included, the tag_of include guard has been defined but tag_of itself hasn't been declared, so nested inclusions of tag_of.hpp do nothing and the build fails. My code builds ok if i either: -Include <utility> myself before Fusion -Remove the include <utility> from tag_of.hpp (it doesnt actually seem to be required - at least, the regression tests all pass with it removed) This seems a bit fragile though. Is there a better way it can be fixed? Thanks, Richard Webb

Richard Webb wrote:
Hi, I've got a project that uses Boost.TR1 (by adding boost/tr1/tr1 to my include path) and Fusion, and i've run into some errors when including the Fusion headers. For example:
boost/fusion/tuple/make_tuple.hpp(21) : error C2027: use of undefined type 'boost::fusion::tuple<>'
boost/fusion/iterator/prior.hpp(50) : error C2039: 'tag_of' : is not a member of 'boost::fusion::detail'
This seems to be caused by the inclusion of <utility> in <boost/fusion/support/tag_of.hpp>, which when using Boost.TR1 like this causes the Fusion headers to be included again. At the point when <utility> is included, the tag_of include guard has been defined but tag_of itself hasn't been declared, so nested inclusions of tag_of.hpp do nothing and the build fails.
My code builds ok if i either: -Include <utility> myself before Fusion -Remove the include <utility> from tag_of.hpp (it doesnt actually seem to be required - at least, the regression tests all pass with it removed)
This seems a bit fragile though. Is there a better way it can be fixed?
Hmmm, confirmed that this is an issue with current SVN trunk, this is tricky to solve and I can't think of a method in TR1 that would work off hand... Joel any ideas if there's an easy (and non-fragile!) way to fix this in fusion? John.
participants (2)
-
John Maddock
-
Richard Webb