-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, while setting up the include paths as specified in the TR1 documentation I stumbled across a Boost.Fusion related compile error (included indirectly from <xpressive/proto/proto.hpp> in my code). After stepping through the include hierarchy, I was able to extract this minimal example, that demonstrates the problem: - -------- START: Test.cpp -------- // Originally included from <boost/xpressive/proto/proto_fwd.hpp> #include <boost/spirit/fusion/sequence/tuple_forward.hpp> // Originally included from #include <boost/xpressive/proto/op_base.hpp> #include <boost/spirit/fusion/sequence/tuple.hpp> - -------- END: Test.cpp -------- With MSVC++ 8.0 SP1 This file fails to compile with certain include path orderings while it compiles fine with others. The error messages are: ...\boost\spirit\fusion\sequence\make_tuple.hpp(23) : error C2027: use of undefined type 'boost::fusion::tuple<>' ...\boost\spirit\fusion\sequence\make_tuple.hpp(23) : error C2079: 'boost::fusion::make_tuple' uses undefined struct 'boost::fusion::tuple<>' ...\include\boost\spirit\fusion\sequence\make_tuple.hpp(24) : error C2514: 'boost::fusion::tuple<>' : class has no constructors Working include path orderings: 1. Any include path ordering that doesn't contain Boost.TR1 2. VC++ Standard Library, regular Boost, Boost.TR1 3. VC++ Standard Library, Boost.TR1, regular Boost Non-working include path orderings: 1. Boost.TR1, regular Boost, VC++ Standard Library [*] 2. Regular Boost, Boost.TR1, VC++ Standard Library [*] Preferred Boost.TR1 setting Generally speaking I would not consider this a problem, as I can simply order the include directories accordingly, but, as far as I understand it, Boost.TR1 can not be expected to work correctly with any of these settings. Regards, Kimon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) iD8DBQFGn3ceIISObEqaPr4RAiszAJ9ipiY+qK+lLg8uDPnHEZejyA5ShwCfQ0fC 1vOMnumqPnguAgtv7co2N8c= =MIsY -----END PGP SIGNATURE-----
Kimon Hoffmann wrote:
while setting up the include paths as specified in the TR1 documentation I stumbled across a Boost.Fusion related compile error (included indirectly from <xpressive/proto/proto.hpp> in my code).
After stepping through the include hierarchy, I was able to extract this minimal example, that demonstrates the problem:
- -------- START: Test.cpp --------
// Originally included from <boost/xpressive/proto/proto_fwd.hpp> #include <boost/spirit/fusion/sequence/tuple_forward.hpp>
// Originally included from #include <boost/xpressive/proto/op_base.hpp> #include <boost/spirit/fusion/sequence/tuple.hpp>
- -------- END: Test.cpp --------
With MSVC++ 8.0 SP1 This file fails to compile with certain include path orderings while it compiles fine with others. The error messages are:
...\boost\spirit\fusion\sequence\make_tuple.hpp(23) : error C2027: use of undefined type 'boost::fusion::tuple<>' ...\boost\spirit\fusion\sequence\make_tuple.hpp(23) : error C2079: 'boost::fusion::make_tuple' uses undefined struct 'boost::fusion::tuple<>' ...\include\boost\spirit\fusion\sequence\make_tuple.hpp(24) : error C2514: 'boost::fusion::tuple<>' : class has no constructors
Working include path orderings: 1. Any include path ordering that doesn't contain Boost.TR1 2. VC++ Standard Library, regular Boost, Boost.TR1 3. VC++ Standard Library, Boost.TR1, regular Boost
Non-working include path orderings: 1. Boost.TR1, regular Boost, VC++ Standard Library [*] 2. Regular Boost, Boost.TR1, VC++ Standard Library
[*] Preferred Boost.TR1 setting
Generally speaking I would not consider this a problem, as I can simply order the include directories accordingly, but, as far as I understand it, Boost.TR1 can not be expected to work correctly with any of these settings.
Correct, since the TR1 library replaces parts of your std lib, you need it's include path before all others. Turned out to be a bit of a maintainance nightmare that one :-( Off hand I can't spot the problem: only the indirect cause - that tuple_basic.hpp never gets included. However, there is a simple temporary fix: put #include <utility> as your first include, and everything *seems* to be OK. It is a bug though, I just can't see what it is in fusion that's causing the failure at present. HTH, John.
John Maddock wrote:
Off hand I can't spot the problem: only the indirect cause - that tuple_basic.hpp never gets included. However, there is a simple temporary fix: put #include <utility> as your first include, and everything *seems* to be OK. It is a bug though, I just can't see what it is in fusion that's causing the failure at present.
I'm confused. HEAD does not have the fusion in the spirit directory since it's been accepted into boost. And, proto does not have the op_base.hpp file anymore. What CVS branch are we talking about? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm confused. HEAD does not have the fusion in the spirit directory since it's been accepted into boost. And, proto does not have the op_base.hpp file anymore. What CVS branch are we talking about?
I am using Boost 1.34.0. I'll try with 1.34.1 RC3 and CVS HEAD later today and give you some feedback. Regards, Kimon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) iD8DBQFGoGtzIISObEqaPr4RArvNAJ4/thXkr0EeIe5H6zksp2Czkhgy7ACguA90 17xiBTTEmQQzPRhx0iKE+W0= =Wmhf -----END PGP SIGNATURE-----
Joel de Guzman wrote:
John Maddock wrote:
Off hand I can't spot the problem: only the indirect cause - that tuple_basic.hpp never gets included. However, there is a simple temporary fix: put #include <utility> as your first include, and everything *seems* to be OK. It is a bug though, I just can't see what it is in fusion that's causing the failure at present.
I'm confused. HEAD does not have the fusion in the spirit directory since it's been accepted into boost. And, proto does not have the op_base.hpp file anymore. What CVS branch are we talking about?
I assume that he's using 1.34: that was what I reproduced the problem with, it may well be moot for 1.35 if cvs HEAD has changed that much though. John.
Hi all,
Off hand I can't spot the problem: only the indirect cause - that tuple_basic.hpp never gets included. However, there is a simple temporary fix: put #include <utility> as your first include, and everything *seems* to be OK. It is a bug though, I just can't see what it is in fusion that's causing the failure at present.
I'm confused. HEAD does not have the fusion in the spirit directory since it's been accepted into boost. And, proto does not have the op_base.hpp file anymore. What CVS branch are we talking about?
now I finally had the time to test this issue with 1.34.1 RC3 and CVS HEAD. As expected the problem persists in 1.34.1 RC3, no modification of the example I provided before is required. With CVS HEAD there still exists a problem, but the error messages are different. Here is a minimal example for CVS HEAD: -------- START: Test.cpp -------- /* * Originally included from * - boost/xpressive/proto/proto.hpp * -- boost/xpressive/proto/operators.hpp * --- boost/xpressive/proto/make_expr.hpp */ #include <boost/fusion/sequence/intrinsic/at.hpp> -------- END: Test.cpp -------- The circumstances under which the problem occurs are the same as with Boost 1.34.0. The example fails to compile when the Boost.TR1 include directory is present in the include path and precedes the Standard Library include directory/directories. Regards, Kimon
Kimon Hoffmann wrote:
Hi all,
With CVS HEAD there still exists a problem, but the error messages are different. Here is a minimal example for CVS HEAD:
-------- START: Test.cpp --------
/* * Originally included from * - boost/xpressive/proto/proto.hpp * -- boost/xpressive/proto/operators.hpp * --- boost/xpressive/proto/make_expr.hpp */ #include <boost/fusion/sequence/intrinsic/at.hpp>
-------- END: Test.cpp --------
The circumstances under which the problem occurs are the same as with Boost 1.34.0. The example fails to compile when the Boost.TR1 include directory is present in the include path and precedes the Standard Library include directory/directories.
Sorry, I can't reproduce the problem with the Test.cpp above. I've tried vc7.1 vc8.0, g++, and comeau. Are you sure that's all that's needed to reproduce the errors? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Sorry, I can't reproduce the problem with the Test.cpp above. I've tried vc7.1 vc8.0, g++, and comeau. Are you sure that's all that's needed to reproduce the errors?
Hmm, now that's odd. I just reviewed my settings and there is nothing special about them. I'm using VC++ 8.0 SP1 (Team Suite), bzw. Are you sure the "regular" Boost include directory is the first, and the Boost.TR1 include directory is the second entry in the global include search path? Regards, Kimon
I can reproduce with VC8, I see: c:\data\boost\develop\boost\boost\fusion\iterator\next.hpp(50) : error C2039: 'tag_of' : is not a member of 'boost::fusion::detail' c:\data\boost\develop\boost\boost\fusion\iterator\next.hpp(52) : see reference to class template instantiation 'boost::fusion::result_of::next<Iterator>' being compiled c:\data\boost\develop\boost\boost\fusion\iterator\next.hpp(50) : error C2146: syntax error : missing ',' before identifier 'tag_of' c:\data\boost\develop\boost\boost\fusion\iterator\next.hpp(50) : error C2065: 'tag_of' : undeclared identifier c:\data\boost\develop\boost\boost\fusion\iterator\next.hpp(50) : error C2977: 'boost::fusion::extension::next_impl' : too many template arguments c:\data\boost\develop\boost\boost\fusion\iterator\next.hpp(24) : see declaration of 'boost::fusion::extension::next_impl' and so on. The boost-root/boost/tr1/tr1 directory should be the *first* include, and boost-root/ the second. As before, including <utility> before the fusion header fixes the errors. John.
John Maddock wrote:
I can reproduce with VC8, I see:
[snip]
and so on. The boost-root/boost/tr1/tr1 directory should be the *first* include, and boost-root/ the second.
As before, including <utility> before the fusion header fixes the errors.
Darned, I must be doing something wrong. Seems the sample Test.cpp Kimon posted is not complete? There's no boost-root/boost/tr1/tr1 include in that Test.cpp at all. Could you please attach a minimal cpp file that exhibits the problem? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Hi Joel,
[...] There's no boost-root/boost/tr1/tr1 include in that Test.cpp at all. Could you please attach a minimal cpp file that exhibits the problem?
Well, that's exactly what is so odd about this problem. You don't need to include anything from TR1, it is sufficient for the TR1 directory to be present in the global include search-path. I try to find another example that exhibits a similar problem, but I can't promise that I'll get it done today. All I can give you for now is the situation I had, when I first encountered the problem: ------- SNIP ------- #include <boost/xpressive/proto/proto.hpp> ------- SNIP ------- Regards, Kimon
Joel de Guzman wrote:
John Maddock wrote:
I can reproduce with VC8, I see:
[snip]
and so on. The boost-root/boost/tr1/tr1 directory should be the *first* include, and boost-root/ the second.
As before, including <utility> before the fusion header fixes the errors.
Darned, I must be doing something wrong. Seems the sample Test.cpp Kimon posted is not complete? There's no boost-root/boost/tr1/tr1 include in that Test.cpp at all. Could you please attach a minimal cpp file that exhibits the problem?
No, there isn't meant to be, to reproduce the problem boost-root/boost/tr1/tr1 should be *in your compilers include path* before the boost-root/ is. John.
Joel de Guzman wrote:
John Maddock wrote:
I can reproduce with VC8, I see:
[snip]
and so on. The boost-root/boost/tr1/tr1 directory should be the *first* include, and boost-root/ the second.
As before, including <utility> before the fusion header fixes the errors.
Darned, I must be doing something wrong. Seems the sample Test.cpp Kimon posted is not complete? There's no boost-root/boost/tr1/tr1 include in that Test.cpp at all. Could you please attach a minimal cpp file that exhibits the problem?
And to try and help this along a bit more: this is a cyclic include dependency problem: Fusion includes <utility> which picks up the TR1 version, which then tries to include fusion (for tuples).... Normally this does work (honestly!), but it's a real pain in the you know where to track down the problem when things go wrong. At present some of the fusion headers simply don't get included at all, and I can't figure out why at present :-( John.
participants (6)
-
Joel de Guzman -
John Maddock -
Kimon Hoffmann