Dear all, Our company makes heavy use of boost libraries. But unfornately some libraries trigger warnings. This is hard to circumvent since we both have level 4 and warnings as error option enabled in Visual Studio 2003. An example is the counting iterator: const std::vector<int> values1(boost::make_counting_iterator(1), boost::make_counting_iterator(10)); gives C4244. This is even harder to supress since the STL is included in the precompiled header. Is it an option to have a good look at this issue for the next release? Note that it is also possible that Plauger's STL is not conforming. Wkr, me
gast128 wrote:
An example is the counting iterator:
const std::vector<int> values1(boost::make_counting_iterator(1), boost::make_counting_iterator(10));
gives C4244. This is even harder to supress since the STL is included in the precompiled header.
This code should really not give you any warnings. (And doesn't on GCC, though I doubt that'll help you.) C4244, so that others don't have to look it up, is the "conversion with possible data loss" warning. This indicates that in VC++, make_counting_iterator returns a counting_iterator<long> or even <__int64>. Can somebody with that compiler post the output of this line? std::cout << typeid(boost::make_counting_iterator(1)).name() << std::endl; A simple workaround for this particular warning ought to be to directly instantiate counting_iterators with their template parameter set correctly. Sebastian Redl
Note: I'm using boost 1.33.1 here Sebastian Redl wrote:
This code should really not give you any warnings. (And doesn't on GCC, though I doubt that'll help you.) C4244, so that others don't have to look it up, is the "conversion with possible data loss" warning. This indicates that in VC++, make_counting_iterator returns a counting_iterator<long> or even <__int64>. Can somebody with that compiler post the output of this line? std::cout << typeid(boost::make_counting_iterator(1)).name() << std::endl;
A simple workaround for this particular warning ought to be to
Using Visual Studio .NET 2003, the output of this was:
class boost::counting_iterator
Sebastian Redl
The problem appears to be when operator += is called on the iterator.
Here, the difference_type of the iterator,
boost::iterator_facade
Lee Houghton wrote:
The problem appears to be when operator += is called on the iterator. Here, the difference_type of the iterator, boost::iterator_facade
::difference_type, which is equal to boost::detail::counting_iterator_base ::difference, is __int64.
OK, that actually makes sense. The typedef searches for the smallest type able to represent all differences between any two numbers of the given type. For signed integers, this is always the next larger signed type. The reason for this is simple: INT_MAX - INT_MIN == UINT_MAX, but INT_MIN - INT_MAX == -UINT_MAX, a number that can only be represented by the next larger signed type. I wonder if this problem is logically solvable, or if a hack (like a static_cast in iterator_adaptor::advance, or perhaps a warning disable) is necessary. Another question is whether this warning should be considered perhaps a bug in VC++. Whatever. Different workaround is to modify boost/iterator/iterator_adaptor.hpp: + #if defined(BOOST_MSVC) + #pragma warning(disable: 4244) + #endif void advance(typename super_t::difference_type n) { BOOST_ITERATOR_ADAPTOR_ASSERT_TRAVERSAL(random_access_traversal_tag) m_iterator += n; } + #if defined(BOOST_MSVC) + #pragma warning(default: 4244) + #endif This is potentially unsafe, of course - nothing prevents you from just passing a HUGE value to +=. The likelyhood, though ... well, it's just a workaround. Sebastian Redl
Sebastian Redl
Whatever. Different workaround is to modify boost/iterator/iterator_adaptor.hpp:
+ #if defined(BOOST_MSVC) + #pragma warning(disable: 4244) + #endif void advance(typename super_t::difference_type n) {
BOOST_ITERATOR_ADAPTOR_ASSERT_TRAVERSAL(random_access_traversal_tag) m_iterator += n; } + #if defined(BOOST_MSVC) + #pragma warning(default: 4244) + #endif
This is potentially unsafe, of course - nothing prevents you from just passing a HUGE value to +=. The likelyhood, though ... well, it's just a workaround.
No static checking (e.g. warning) can protect you from the possibility of runtime overflows in integer operations. The overflow can occur with or without the warning disabled. These "integer size warnings" are nothing more than a nuisance in most generic code. IMO they should be turned off on the command line. Turning them off in individual source files leaves them cluttered with workarounds and #ifdefs. -- Dave Abrahams Boost Consulting www.boost-consulting.com
It looks like that warning is generated due to /W64 (Detect 64-bit
portability issues) command line option. If you disable it I bet the
warning will go away. Although this option looks helpful, I think it
generates false possitives. For example it will generate a warning if you
assign a size_t to an unsigned int due to how size_t is defined with this
command line option enabled.
On Thu, 26 Jan 2006 03:37:33 -0700, gast128
Dear all,
Our company makes heavy use of boost libraries. But unfornately some libraries trigger warnings. This is hard to circumvent since we both have level 4 and warnings as error option enabled in Visual Studio 2003.
An example is the counting iterator:
const std::vector<int> values1(boost::make_counting_iterator(1), boost::make_counting_iterator(10));
gives C4244. This is even harder to supress since the STL is included in the precompiled header.
Is it an option to have a good look at this issue for the next release? Note that it is also possible that Plauger's STL is not conforming.
Wkr, me
-- Orhun Birsoy
participants (5)
-
David Abrahams
-
gast128
-
Lee Houghton
-
Orhun Birsoy
-
Sebastian Redl