[1.41.0] [integer] integer.hpp does not compile in MSVC 8.0 with /Za option on

An empty CPP file containing only inclusion of <boost/integer.hpp>: --------------- #include <boost/integer.hpp> --------------- does not compile in MS Visual Studio 8.0 Standard when /Za option ("Disable Language Extensions") is used. The output is following: --------------- D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(70) : error C2039: 'long_long_type' : is not a member of 'boost' D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(70) : error C2065: 'long_long_type' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(70) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(73) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(67) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(73) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(79) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(85) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(119) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(126) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(132) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(138) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(144) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(150) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(156) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer.hpp(88) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(94) : see reference to class template instantiation 'boost::int_max_value_t<MaxValue>' being compiled D:\Libraries\boost_1_41_0\boost/integer.hpp(89) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(90) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(91) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(101) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(107) : see reference to class template instantiation 'boost::int_min_value_t<MinValue>' being compiled D:\Libraries\boost_1_41_0\boost/integer.hpp(102) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(103) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(104) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(116) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(122) : see reference to class template instantiation 'boost::uint_value_t<Value>' being compiled D:\Libraries\boost_1_41_0\boost/integer.hpp(117) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(118) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(119) : error C2065: 'const_max' : undeclared identifier --------------- I suppose this happens to other editions as well. Also it seems that the same happens with 2005 version. 1.40 version had the same problem and I reported it but it seems no one cared about it. Adam Badura

I suppose this happens to other editions as well. Also it seems that the same happens with 2005 version. 1.40 version had the same problem and I reported it but it seems no one cared about it.
Can you please file a bug report at svn.boost.org? Boost.Integer's author appears to be missing in action at present, but if no one else steps up to the plate, I plan on doing some minimal maintenance work to this important little library soon... HTH, John.

John Maddock wrote:
Boost.Integer's author appears to be missing in action at present, but if no one else steps up to the plate, I plan on doing some minimal maintenance work to this important little library soon... Could be nice of you if you also had support for 64bits types then cause currently uint_t<N> only goes up to 32. Shoudl I fill a ticket too ?
-- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

Boost.Integer's author appears to be missing in action at present, but if no one else steps up to the plate, I plan on doing some minimal maintenance work to this important little library soon... Could be nice of you if you also had support for 64bits types then cause currently uint_t<N> only goes up to 32. Shoudl I fill a ticket too ?
Wouldn't hurt ;-) John.

joel wrote:
Could be nice of you if you also had support for 64bits types then cause currently uint_t<N> only goes up to 32.
Hi Joel, I thought this was fixed by https://svn.boost.org/trac/boost/changeset/47414 , no? (I have been using a privately-hacked version of integer.hpp for a long time, but thought this was now unnecessary.) Phil.

Could be nice of you if you also had support for 64bits types then cause currently uint_t<N> only goes up to 32.
Hi Joel,
I thought this was fixed by https://svn.boost.org/trac/boost/changeset/47414 , no? (I have been using a privately-hacked version of integer.hpp for a long time, but thought this was now unnecessary.)
Sigh... it never made it out of Trunk into Release (tests never passed on anything except gcc). I'll look into it, John.

2009/11/22 joel <joel.falcou@lri.fr>:
John Maddock wrote:
Boost.Integer's author appears to be missing in action at present, but if no one else steps up to the plate, I plan on doing some minimal maintenance work to this important little library soon...
Could be nice of you if you also had support for 64bits types then cause currently uint_t<N> only goes up to 32. Shoudl I fill a ticket too ?
Looks like there's a three-year-old ticket for that: https://svn.boost.org/trac/boost/ticket/653

Scott McMurray wrote:
Looks like there's a three-year-old ticket for that: https://svn.boost.org/trac/boost/ticket/653
It is not merged at least

Boost.Integer's author appears to be missing in action at present, but if no one else steps up to the plate, I plan on doing some minimal maintenance work to this important little library soon...
Could be nice of you if you also had support for 64bits types then cause currently uint_t<N> only goes up to 32. Shoudl I fill a ticket too ?
Those changes got removed when we reverted integer back to the last known "good" state earlier this month. I'll reopen and try and fix properly, John.

Can you please file a bug report at svn.boost.org?
I did. https://svn.boost.org/trac/boost/ticket/3657
Boost.Integer's author appears to be missing in action at present, but if no one else steps up to the plate, I plan on doing some minimal maintenance work to this important little library soon...
It seems correction of this error is simple so it should not be a problem. But can it be done earlier then 1.42? Adam Badura

Boost.Integer's author appears to be missing in action at present, but if no one else steps up to the plate, I plan on doing some minimal maintenance work to this important little library soon...
It seems correction of this error is simple so it should not be a problem. But can it be done earlier then 1.42?
No. 1.41 is released now, there won't be another release until 1.42. John.

It seems correction of this error is simple so it should not be a problem. But can it be done earlier then 1.42?
No.
1.41 is released now, there won't be another release until 1.42.
But the number is 1.41.0 so there could be 1.41.1... ;) Adam Badura

It seems correction of this error is simple so it should not be a problem. But can it be done earlier then 1.42?
No.
1.41 is released now, there won't be another release until 1.42.
But the number is 1.41.0 so there could be 1.41.1... ;)
Technically - but not just for this issue - and based on past history I'd say the chances are only very slightly non-zero! John.

I tracked the error myself a bit and it seems in comes from what appears to be a bug in "config/compiler/visualc.hpp". There at lines 128-132 we have: --------------- #if (_MSC_VER >= 1310) && defined(_MSC_EXTENSIONS) # define BOOST_HAS_LONG_LONG #else # define BOOST_NO_LONG_LONG #endif --------------- _MSC_EXTENSIONS is defined only if /Za option is used (extensions are enabled). Otherwise it is not defined. But MS VS recognizes "long long" and "unsigned long long" regardless of whether extensions are enabled or disabled. So this part of the preprocessor condition is not needed. Even more. I think this exposes other problems in Boost libraries. The error first shows up in "integer_fwd.hpp" header at lines 68-74, where there is: --------------- #ifdef ULLONG_MAX template < > class integer_traits< ::boost::long_long_type>; template < > class integer_traits< ::boost::ulong_long_type >; #endif --------------- Why this checks for ULLONG_MAX rather then BOOST_HAS_LONG_LONG / BOOST_NO_LONG_LONG? If it did check for the second one then there would be no error (however Boost would still inccorectly assume that "long long" and "unsigned long long" are not available). So either the code there should use BOOST_HAS_LONG_LONG / BOOST_NO_LONG_LONG or it should check for consistency of those two and ULLONG_MAX. Adam Badura
participants (6)
-
Adam Badura
-
joel
-
Joel Falcou
-
John Maddock
-
Phil Endecott
-
Scott McMurray