[Multi-Index] Suppressing warnings in VS2005 (VC8)

(I'm not sure this is strictly related to Multi-Index in fact) Hi. If I #include <boost/multi_index_container.hpp> #include <boost/multi_index/random_access_index.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/hashed_index.hpp> #include <boost/multi_index/composite_key.hpp> #include <boost/multi_index/mem_fun.hpp> I get boost\detail\allocator_utilities.hpp(182) : warning C4100: 'p' : unreferenced formal parameter (we compile with a low threshold for warnings) If I try to suppress it with: #if defined(_WIN32) && defined( _MSC_VER ) #pragma warning(push) #pragma warning(disable : 4100) // unreferenced formal parameter #endif #include <boost/multi_index_container.hpp> #include <boost/multi_index/random_access_index.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/hashed_index.hpp> #include <boost/multi_index/composite_key.hpp> #include <boost/multi_index/mem_fun.hpp> #if defined(_WIN32) && defined( _MSC_VER ) #pragma warning(pop) #endif I get even more warnings (way more). I suspect that I'm getting in the way of a built-in mechanism in Boost to suppress warnings with my own #pragma warning push/pop. So my question is how I can suppress this one little warning (well, because of the instantiation trail of the B.MI, it's a 65 lines "little" warning...) without disabling Boost's own warning suppression? Thanks, --DD

Hi Dominique, ________________________________________ De: boost-users-bounces@lists.boost.org [boost-users-bounces@lists.boost.org] En nombre de Dominique Devienne [ddevienne@gmail.com] Enviado el: martes, 07 de abril de 2009 19:18 Para: boost-users Asunto: [Boost-users] [Multi-Index] Suppressing warnings in VS2005 (VC8)
(I'm not sure this is strictly related to Multi-Index in fact)
Hi. If I
#include <boost/multi_index_container.hpp> #include <boost/multi_index/random_access_index.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/hashed_index.hpp> #include <boost/multi_index/composite_key.hpp> #include <boost/multi_index/mem_fun.hpp>
I get
boost\detail\allocator_utilities.hpp(182) : warning C4100: 'p' : unreferenced formal parameter
I've checked this out, the spurious warning seems to happen when the elements of the multi_index_container (which are destroyed via boost::detail::allocator::destroy) are classes with a trivial destructor.
If I try to suppress it with: [...] I get even more warnings (way more).
It' weird, because I tried it myself and the warning indeed disappears (MSVC 8.0): #define SUPPRESS_C4100 #ifdef SUPPRESS_C4100 #if defined(_WIN32) && defined( _MSC_VER ) #pragma warning(push) #pragma warning(disable : 4100) // unreferenced formal parameter #endif #endif #include <boost/multi_index_container.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/identity.hpp> #ifdef SUPPRESS_C4100 #if defined(_WIN32) && defined( _MSC_VER ) #pragma warning(pop) #endif #endif struct foo{}; bool operator<(foo,foo){return false;} int main() { boost::multi_index_container<foo> c; } Can you double check you didn't make any mistake? If the additional warnings still pop up, can you paste them to a file and post it? Also, this should proably be fixed at the level of boost/detail/allocator_utilities.hpp. If you put a ticket so that I remember I'll try to get at it in a few days. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

On Tue, Apr 7, 2009 at 1:31 PM, JOAQUIN M. LOPEZ MUÑOZ <joaquin@tid.es> wrote:
Hi Joaquín,
It' weird, because I tried it myself and the warning indeed disappears (MSVC 8.0):
I can replicate your findings on a small test file.
Can you double check you didn't make any mistake? If the additional warnings still pop up, can you paste them to a file and post it?
I did. I can't explain it. There's lots more code following the BMI includes though. I tried to add stuff to your small example to make it behave the same way, but I gave up, I have more productive work to do too ;-) We compile with /W4 /Wp64 BTW.
Also, this should probably be fixed at the level of boost/detail/allocator_utilities.hpp. If you put a ticket so that I remember I'll try to get at it in a few days.
I'll try to find out how to open a ticket. Thanks, --DD

Dominique Devienne escribió:
On Tue, Apr 7, 2009 at 1:31 PM, JOAQUIN M. LOPEZ MUÑOZ <joaquin@tid.es> wrote:
Hi Joaquín,
It' weird, because I tried it myself and the warning indeed disappears (MSVC 8.0):
I can replicate your findings on a small test file.
Can you double check you didn't make any mistake? If the additional warnings still pop up, can you paste them to a file and post it?
I did. I can't explain it. There's lots more code following the BMI includes though.
I tried to add stuff to your small example to make it behave the same way, but I gave up, I have more productive work to do too ;-)
Dominique, Could you please try replacing your copy of boost/detail/allocator_utilities.hpp with the one attached? Do things improve? If so I'll commit this to the trunk. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo /* Copyright 2003-2009 Joaquin M Lopez Munoz. * Distributed under the Boost Software License, Version 1.0. * (See accompanying file LICENSE_1_0.txt or copy at * http://www.boost.org/LICENSE_1_0.txt) * * See Boost website at http://www.boost.org/ */ #ifndef BOOST_DETAIL_ALLOCATOR_UTILITIES_HPP #define BOOST_DETAIL_ALLOCATOR_UTILITIES_HPP #include <boost/config.hpp> /* keep it first to prevent nasty warns in MSVC */ #include <boost/detail/workaround.hpp> #include <boost/mpl/aux_/msvc_never_true.hpp> #include <boost/mpl/eval_if.hpp> #include <boost/type_traits/is_same.hpp> #include <cstddef> #include <memory> #include <new> namespace boost{ namespace detail{ /* Allocator adaption layer. Some stdlibs provide allocators without rebind * and template ctors. These facilities are simulated with the external * template class rebind_to and the aid of partial_std_allocator_wrapper. */ namespace allocator{ /* partial_std_allocator_wrapper inherits the functionality of a std * allocator while providing a templatized ctor and other bits missing * in some stdlib implementation or another. */ template<typename Type> class partial_std_allocator_wrapper:public std::allocator<Type> { public: /* Oddly enough, STLport does not define std::allocator<void>::value_type * when configured to work without partial template specialization. * No harm in supplying the definition here unconditionally. */ typedef Type value_type; partial_std_allocator_wrapper(){}; template<typename Other> partial_std_allocator_wrapper(const partial_std_allocator_wrapper<Other>&){} partial_std_allocator_wrapper(const std::allocator<Type>& x): std::allocator<Type>(x) { }; #if defined(BOOST_DINKUMWARE_STDLIB) /* Dinkumware guys didn't provide a means to call allocate() without * supplying a hint, in disagreement with the standard. */ Type* allocate(std::size_t n,const void* hint=0) { std::allocator<Type>& a=*this; return a.allocate(n,hint); } #endif }; /* Detects whether a given allocator belongs to a defective stdlib not * having the required member templates. * Note that it does not suffice to check the Boost.Config stdlib * macros, as the user might have passed a custom, compliant allocator. * The checks also considers partial_std_allocator_wrapper to be * a standard defective allocator. */ #if defined(BOOST_NO_STD_ALLOCATOR)&&\ (defined(BOOST_HAS_PARTIAL_STD_ALLOCATOR)||defined(BOOST_DINKUMWARE_STDLIB)) template<typename Allocator> struct is_partial_std_allocator { BOOST_STATIC_CONSTANT(bool, value= (is_same< std::allocator<BOOST_DEDUCED_TYPENAME Allocator::value_type>, Allocator >::value)|| (is_same< partial_std_allocator_wrapper< BOOST_DEDUCED_TYPENAME Allocator::value_type>, Allocator >::value)); }; #else template<typename Allocator> struct is_partial_std_allocator { BOOST_STATIC_CONSTANT(bool,value=false); }; #endif /* rebind operations for defective std allocators */ template<typename Allocator,typename Type> struct partial_std_allocator_rebind_to { typedef partial_std_allocator_wrapper<Type> type; }; /* rebind operation in all other cases */ #if BOOST_WORKAROUND(BOOST_MSVC,<1300) /* Workaround for a problem in MSVC with dependent template typedefs * when doing rebinding of allocators. * Modeled after <boost/mpl/aux_/msvc_dtw.hpp> (thanks, Aleksey!) */ template<typename Allocator> struct rebinder { template<bool> struct fake_allocator:Allocator{}; template<> struct fake_allocator<true> { template<typename Type> struct rebind{}; }; template<typename Type> struct result: fake_allocator<mpl::aux::msvc_never_true<Allocator>::value>:: template rebind<Type> { }; }; #else template<typename Allocator> struct rebinder { template<typename Type> struct result { typedef typename Allocator::BOOST_NESTED_TEMPLATE rebind<Type>::other other; }; }; #endif template<typename Allocator,typename Type> struct compliant_allocator_rebind_to { typedef typename rebinder<Allocator>:: BOOST_NESTED_TEMPLATE result<Type>::other type; }; /* rebind front-end */ template<typename Allocator,typename Type> struct rebind_to: mpl::eval_if_c< is_partial_std_allocator<Allocator>::value, partial_std_allocator_rebind_to<Allocator,Type>, compliant_allocator_rebind_to<Allocator,Type>
{ }; /* allocator-independent versions of construct and destroy */ template<typename Type> void construct(void* p,const Type& t) { new (p) Type(t); } #if BOOST_WORKAROUND(BOOST_MSVC,BOOST_TESTED_AT(1500)) /* MSVC++ issues spurious warnings about unreferencend formal parameters * in destroy<Type> when Type is a class with trivial dtor. */ #pragma warning(push) #pragma warning(disable:4100) #endif template<typename Type> void destroy(const Type* p) { #if BOOST_WORKAROUND(__SUNPRO_CC,BOOST_TESTED_AT(0x590)) const_cast<Type*>(p)->~Type(); #else p->~Type(); #endif } #if BOOST_WORKAROUND(BOOST_MSVC,BOOST_TESTED_AT(1500)) #pragma warning(pop) #endif } /* namespace boost::detail::allocator */ } /* namespace boost::detail */ } /* namespace boost */ #endif

On Mon, Apr 13, 2009 at 7:11 AM, <joaquin@tid.es> wrote:
Could you please try replacing your copy of boost/detail/allocator_utilities.hpp with the one attached? Do things improve? If so I'll commit this to the trunk.
Hi Joaquín, With your modified allocator_utilities.hpp I now get a clean compile. Thanks for taking the time to fix this! Best regards, --DD
participants (3)
-
Dominique Devienne
-
JOAQUIN M. LOPEZ MUÑOZ
-
joaquin@tid.es