is_enum and is_convertible interdependencies....BOOST_NO_IS_ABSTRACT
Hi, This is my first post here, so please do not hesitate in letting me know if this is not the correct forum for my question. I am running our front end through the regression tests for boost 1.33.1. Using the same compiler configuration we have been able to get through the regression for 1.32.0. In 1.33.1, we are producing an error that is_convertible is not a type on line 95 of boost/type_traits/is_enum.hpp. We get this error when running tests in libs/filesystem/test. From what I can tell, the problem is that is_convertible requires is_enum be defined which in turn requires is_convertible to be defined. The include path for the particular test has: boost/filesystem/exception.hpp-> /boost/filesystem/path.hpp /boost/filesystem/path.hpp-> boost/iterator/iterator_facade.hpp boost/iterator/iterator_facade.hpp-> boost/iterator/interoperable.hpp boost/iterator/interoperable.hpp-> boost/type_traits/is_convertible.hpp [This include is conditional on BOOST_NO_IS_ABSTRACT] boost/type_traits/is_convertible.hpp-> boost/type_traits/is_abstract.hpp boost/type_traits/is_abstract.hpp-> boost/type_traits/is_class.hpp boost/type_traits/is_class.hpp-> boost/type_traits/is_scalar.hpp boost/type_traits/is_scalar.hpp-> boost/type_traits/is_enum.hpp Setting BOOST_NO_IS_ABSTRACT does solve the issue, however I don't think it is the *best* solution. Any help appreciated. Regards, Richard
Richard Corden wrote:
Hi,
I am running our front end through the regression tests for boost 1.33.1. Using the same compiler configuration we have been able to get through the regression for 1.32.0.
[...] It could help very much if you tell us which configuration (compiler...) you are using. It's also possible that you can find appropriate test results and comments on failing tests for particular configurations at http://engineering.meta-comm.com/boost.aspx Stefan
Hi Stefan, Thank you for your quick reply. Stefan Slapeta wrote:
It could help very much if you tell us which configuration (compiler...) you are using.
I work for a company that develops static analysis tools. Therefore I am using our own tool, and so our own configuration. This is the contents of our hpp in boost/config/compiler/ // Definitions for running over boost #define BOOST_HAS_LONG_LONG #define _GLIBCPP_USE_LONG_LONG #define LONG_LONG long long
It's also possible that you can find appropriate test results and comments on failing tests for particular configurations at http://engineering.meta-comm.com/boost.aspx
Thank you for the link. 'filesystem' passes cleanly for all compilers listed. I normally work on the assumption that boost is right and to date, except for a few missing stl headers in some tests, this has been the case. In this instance however I have been trying to work out how without defining BOOST_NO_IS_ABSTRACT is_convertible can compile and I have not been able to do so. Thanks for your time. Regards, Richard
Richard Corden wrote:
Any help appreciated.
One cheeky solution would be to provide intrinsic support for type traits - like Microsoft and Metrowerks. In fact, some traits cannot be completely implemented otherwise (eg. is_union) However, I imagine you also want to track and fix the root cause here too, and there I am of little help ;?) -- AlisdairM
This is my first post here, so please do not hesitate in letting me know if this is not the correct forum for my question.
This is fine.
In 1.33.1, we are producing an error that is_convertible is not a type on line 95 of boost/type_traits/is_enum.hpp. We get this error when running tests in libs/filesystem/test.
From what I can tell, the problem is that is_convertible requires is_enum be defined which in turn requires is_convertible to be defined. The include path for the particular test has:
boost/filesystem/exception.hpp-> /boost/filesystem/path.hpp /boost/filesystem/path.hpp-> boost/iterator/iterator_facade.hpp boost/iterator/iterator_facade.hpp-> boost/iterator/interoperable.hpp boost/iterator/interoperable.hpp-> boost/type_traits/is_convertible.hpp
[This include is conditional on BOOST_NO_IS_ABSTRACT] boost/type_traits/is_convertible.hpp-> boost/type_traits/is_abstract.hpp
boost/type_traits/is_abstract.hpp-> boost/type_traits/is_class.hpp boost/type_traits/is_class.hpp-> boost/type_traits/is_scalar.hpp boost/type_traits/is_scalar.hpp-> boost/type_traits/is_enum.hpp
Setting BOOST_NO_IS_ABSTRACT does solve the issue, however I don't think it is the *best* solution.
OK, I see the issue: there is a cyclic dependency, however all the other compilers for which we can implement is_abstract we also define BOOST_TT_HAS_CONFORMING_IS_CLASS_IMPLEMENTATION which neatly avoids the cyclic dependency. I'm not sure how to fix this one except to advise you to try setting the above macro. Of course if your tool is available to third parties this may not be the ideal solution for them... ? John.
John Maddock wrote:
OK, I see the issue: there is a cyclic dependency, however all the other compilers for which we can implement is_abstract we also define BOOST_TT_HAS_CONFORMING_IS_CLASS_IMPLEMENTATION which neatly avoids the cyclic dependency.
This works perfectly. Thanks for the tip.
I'm not sure how to fix this one except to advise you to try setting the above macro. Of course if your tool is available to third parties this may not be the ideal solution for them... ?
I am actually using boost to help ensure that our tool can first handle 100% compliant C++ (It amazes me how you guys can manage to keep the code at such a high quality level). To do this I run the regression tests without any compiler workarounds enabled. When a third party uses our tools, they will use our tool in a way that emulates their target compiler, and so will be using one of the existing configurations. Thank you for tracking this down for me. Kind Regards, Richard
Richard Corden <richard.corden@gmail.com> writes:
John Maddock wrote:
OK, I see the issue: there is a cyclic dependency, however all the other compilers for which we can implement is_abstract we also define BOOST_TT_HAS_CONFORMING_IS_CLASS_IMPLEMENTATION which neatly avoids the cyclic dependency.
This works perfectly. Thanks for the tip.
Didn't we decide that flags for conformance should always be in the form of BOOST_NO_some-conforming-c++-feature so that unless something special is done, the assumption will be that the compiler conforms? -- Dave Abrahams Boost Consulting www.boost-consulting.com
Didn't we decide that flags for conformance should always be in the form of
BOOST_NO_some-conforming-c++-feature
so that unless something special is done, the assumption will be that the compiler conforms?
Absolutely: however BOOST_TT_HAS_CONFORMING_IS_CLASS_IMPLEMENTATION was one of yours I believe: chuckles, ducks, runs for cover.... John.
"John Maddock" <john@johnmaddock.co.uk> writes:
Didn't we decide that flags for conformance should always be in the form of
BOOST_NO_some-conforming-c++-feature
so that unless something special is done, the assumption will be that the compiler conforms?
Absolutely: however BOOST_TT_HAS_CONFORMING_IS_CLASS_IMPLEMENTATION was one of yours I believe: chuckles, ducks, runs for cover....
<dave quietly whistles "dixie" while hoping nobody notices he's checking in the fix> -- Dave Abrahams Boost Consulting www.boost-consulting.com
John Maddock writes:
Didn't we decide that flags for conformance should always be in the form of
BOOST_NO_some-conforming-c++-feature
so that unless something special is done, the assumption will be that the compiler conforms?
Absolutely: however BOOST_TT_HAS_CONFORMING_IS_CLASS_IMPLEMENTATION was one of yours I believe
That was one of mine actually; I'm pretty sure I've introduced it before we've agreed on the above, though. -- Aleksey Gurtovoy MetaCommunications Engineering
participants (6)
-
Aleksey Gurtovoy -
AlisdairM -
David Abrahams -
John Maddock -
Richard Corden -
Stefan Slapeta