Re: [Boost-users] [1.33.0] Release candidate #1 is available
I'm getting a compile error with my code to do with the
boost::is_abstract class for compilers that don't support
type_traits/is_abstract, i.e. those that have BOOST_NO_IS_ABSTRACT
defined, BCB 5.6.4 in my case.
Serialization/is_abstract.hpp defines an is_abstract class if
BOOST_NO_IS_ABSTRACT is defined rather than including
type_traits/is_abstract.hpp. With 1.33 RC1 type_traits/is_abstract.hpp
now defines an is_abstract class if BOOST_NO_IS_ABSTRACT is defined,
which it didn't use to do. Thus the class boost::is_abstract is
multiply defined.
Minimal code to reproduce the error is:
#include
It's always a good idea to put the names of the libraries concerned in
your subject line:
http://boost-consulting.com/boost/more/discussion_policy.htm#effective
"Richard Jennings"
I'm getting a compile error with my code to do with the boost::is_abstract class for compilers that don't support type_traits/is_abstract, i.e. those that have BOOST_NO_IS_ABSTRACT defined, BCB 5.6.4 in my case.
Serialization/is_abstract.hpp defines an is_abstract class if BOOST_NO_IS_ABSTRACT is defined rather than including type_traits/is_abstract.hpp. With 1.33 RC1 type_traits/is_abstract.hpp now defines an is_abstract class if BOOST_NO_IS_ABSTRACT is defined, which it didn't use to do. Thus the class boost::is_abstract is multiply defined.
Minimal code to reproduce the error is:
#include
#include int main(int argc, char* argv[]) { return 0; }
Compile that with BCB5.6.4 and you get: [C++ Error] is_abstract.hpp(32): E2238 Multiple declaration for 'is_abstract<T>' [C++ Error] is_abstract.hpp(130): E2344 Earlier declaration of 'is_abstract<T>'
The first is serialization/is_abstract.hpp the second is type_traits/is_abstract.hpp.
Perhaps serialization/is_abstract.hpp could check for type_traits/is_abstract.hpp having already been included or perhaps the serialization version is not now needed?
Richard
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Doug Gregor Sent: 01 August 2005 18:04 To: boost-users@lists.boost.org Subject: [Boost-users] [1.33.0] Release candidate #1 is available
Boost 1.33.0 release candidate #1 is now available here:
http://www.osl.iu.edu/~dgregor/boost-1.33.0/
There are two sets of files important for this release:
- boost_1_33_0_rc1.*: The actual release candidate - boost_1_33_0_(docbook|fo|man).*: The documentation in other formats
Please download and unpack the archives, browse the documentation, try the release with your favorite compiler, etc.
Thanks! Doug Gregor 1.33.0 Release Manager
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Dave Abrahams Boost Consulting www.boost-consulting.com
When I look at the new code in type_traits/is_abstract for compilers which can't implement correct is_abstract, it seems it marks any polymophic class as abstract. This would conflict with the serialization system which really needs to know if a class is really abstract - not just polymorphic. I would be curious as to why type_traits/is_abstract makes this the default. The serialization system makes "false" the default. Robert Ramey Richard Jennings wrote:
I'm getting a compile error with my code to do with the boost::is_abstract class for compilers that don't support type_traits/is_abstract, i.e. those that have BOOST_NO_IS_ABSTRACT defined, BCB 5.6.4 in my case.
Serialization/is_abstract.hpp defines an is_abstract class if BOOST_NO_IS_ABSTRACT is defined rather than including type_traits/is_abstract.hpp. With 1.33 RC1 type_traits/is_abstract.hpp now defines an is_abstract class if BOOST_NO_IS_ABSTRACT is defined, which it didn't use to do. Thus the class boost::is_abstract is multiply defined.
Minimal code to reproduce the error is:
#include
#include int main(int argc, char* argv[]) { return 0; }
Compile that with BCB5.6.4 and you get: [C++ Error] is_abstract.hpp(32): E2238 Multiple declaration for 'is_abstract<T>' [C++ Error] is_abstract.hpp(130): E2344 Earlier declaration of 'is_abstract<T>'
The first is serialization/is_abstract.hpp the second is type_traits/is_abstract.hpp.
Perhaps serialization/is_abstract.hpp could check for type_traits/is_abstract.hpp having already been included or perhaps the serialization version is not now needed?
Richard
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Doug Gregor Sent: 01 August 2005 18:04 To: boost-users@lists.boost.org Subject: [Boost-users] [1.33.0] Release candidate #1 is available
Boost 1.33.0 release candidate #1 is now available here:
http://www.osl.iu.edu/~dgregor/boost-1.33.0/
There are two sets of files important for this release:
- boost_1_33_0_rc1.*: The actual release candidate - boost_1_33_0_(docbook|fo|man).*: The documentation in other formats
Please download and unpack the archives, browse the documentation, try the release with your favorite compiler, etc.
Thanks! Doug Gregor 1.33.0 Release Manager
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
So what can be done to stop these conflicts? Forcing header include orders on us isn't very practical, especially for unrelated libraries such as this (it is acceptable for the dependency order imposed between archive/serialization) as they are related) but it isn't practical in a large project to know which headers may include type_traits (directly or indirectly) and then make sure they are included after serialization headers. Thanks Russell Robert Ramey wrote:
When I look at the new code in type_traits/is_abstract for compilers which can't implement correct is_abstract, it seems it marks any polymophic class as abstract. This would conflict with the serialization system which really needs to know if a class is really abstract - not just polymorphic. I would be curious as to why type_traits/is_abstract makes this the default. The serialization system makes "false" the default.
When I look at the new code in type_traits/is_abstract for compilers which can't implement correct is_abstract, it seems it marks any polymophic class as abstract. This would conflict with the serialization system which really needs to know if a class is really abstract - not just polymorphic. I would be curious as to why type_traits/is_abstract makes this the default. The serialization system makes "false" the default.
The announcement of the change was made last year, I'm pretty sure I cc'd you, but in any case it's here: http://lists.boost.org/Archives/boost/2004/12/77173.php The original discussion (or some of it anyway) can be found here: http://lists.boost.org/Archives/boost/2004/11/76883.php John.
Hmm - I missed that discussion. I did get your email - but somehow it failed to register. I'll look into this. Robert Ramey. P.S. FWIW - I would have suggested a static assert in a place where a user invokes a template metafunction which can't be counted on to do what its names suggests it does in the current environment. RR John Maddock wrote:
When I look at the new code in type_traits/is_abstract for compilers which can't implement correct is_abstract, it seems it marks any polymophic class as abstract. This would conflict with the serialization system which really needs to know if a class is really abstract - not just polymorphic. I would be curious as to why type_traits/is_abstract makes this the default. The serialization system makes "false" the default.
The announcement of the change was made last year, I'm pretty sure I cc'd you, but in any case it's here: http://lists.boost.org/Archives/boost/2004/12/77173.php
The original discussion (or some of it anyway) can be found here: http://lists.boost.org/Archives/boost/2004/11/76883.php
John.
Hmm - I missed that discussion. I did get your email - but somehow it failed to register. I'll look into this.
One simple answer would be to move your version into a separate namespace, then when BOOST_NO_IS_ABSTRACT is *not* defined then it would just default to a simple using declaration, otherwise you could define your own workaround version. John.
participants (5)
-
David Abrahams -
John Maddock -
Richard Jennings -
Robert Ramey -
Russell Hind