Boost C++ Libraries: Ticket #4669: Lots of warnings from is_unsigned.hpp

Tue, 21 Sep 2010 20:36:47 GMT

Using gcc-4.2.1, is_unsigned_values (via the macro BOOST_STATIC_CONSTANT) becomes:

template <class T>
struct is_unsigned_values
{

typedef typename remove_cv<T>::type no_cv_t;
enum { minus_one = (static_cast<no_cv_t>(-1)) };
enum { zero = (static_cast<no_cv_t>(0)) };

};

Using gcc-4.4.5 (debian), it expands to.

template <class T>
struct is_unsigned_values
{

typedef typename remove_cv<T>::type no_cv_t;
static const no_cv_t minus_one = (static_cast<no_cv_t>(-1));
static const no_cv_t zero = (static_cast<no_cv_t>(0));

};

status changed; resolution set

John Maddock — Wed, 22 Sep 2010 08:45:43 GMT

status new → closed
resolution → worksforme

I'm unable to reproduce this here: Boost.Config never sets BOOST_NO_INCLASS_MEMBER_INITIALIZATION for any gcc compiler version (which is what would cause BOOST_STATIC_CONSTANT to use enum's rather than a true static constant).

In addition all the type_traits are currently run with -Wall -pedantic -Werror and all the tests are passing even on the BSD platforms that are tested: http://beta.boost.org/development/tests/trunk/developer/type_traits.html

However, some testing reveals that using an enum in this context causes is_unsigned to malfunction anyway, so I'll change the code to always use a static constant.

I'd be interested in knowing why BOOST_NO_INCLASS_MEMBER_INITIALIZATION is being set on this platform/compiler combination - are you using a modified Boost version at all?

John Maddock — Wed, 22 Sep 2010 08:48:02 GMT

(In [65531]) Change these two traits to always use a static constant and not BOOST_STATIC_CONSTANT - otherwise they don't work! Refs #4669.

Wed, 22 Sep 2010 14:40:21 GMT

Non-standard it is. Found out that it is the FreeBSD port that adds the following:

//
// gcc previous to 4.3.x does not implement inclass member initialization
//
#if (__GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ <= 2))
#  define BOOST_NO_INCLASS_MEMBER_INITIALIZATION
#endif

Which is not exactly true, more likely it is a workaround for the problem described in #4381.