Boost logo

Boost :

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2004-01-09 19:33:11


I'm fixing the compilation problems with VC7.1 for the recently accepted
Numeric Conversions Library and found the following:

I erroneously used a construct of the follwing form:

typedef typename boost::is_same<T,S>::type is_trivial ;

typedef typename boost::mpl::if_<is_trivial,ABC,DEF>::type type ;

The error is in the "::type" after is_same<>; mpl::if_ can take the traits
as is, without the "::type"

However, that code did pass many of the other compilers, so that "::type"
does exist in some cases.

Is this a bug in the VC7.1 version of "is_same"? That is, was it intended to
have "::type"?

VC7.1 doesn't like the implementation of "mpl::equal_to" when the operands
are "mpl::integral_c" of ENUMERATION type.
The problem is certainly related to the fact that the value_type to compare
is an enum.

I wonder if this is a general problem and I shouldn't use enums, at least
for some compilers.. does anyone know?

Assuming that using enums is OK, so that "equal_to" has to be fixed, I
change the code to use my own version of equal_to, as follows:

template<class T1, T1 val1, class T2, T2 val2>

struct equal_to_helper
  BOOST_STATIC_CONSTANT(bool, value = ( val1 == val2 ) ) ;
} ;

template< typename BOOST_MPL_AUX_VOID_SPEC_PARAM(T1)
               , typename BOOST_MPL_AUX_VOID_SPEC_PARAM(T2)
struct equal_to
  typedef typename T1::value_type T1_val_type ;
  typedef typename T2::value_type T2_val_type ;
  typedef equal_to_helper< T1_val_type
> helper ;

BOOST_MPL_AUX_VALUE_WKND(helper)::value );

#if !defined(__BORLANDC__)
  typedef mpl::bool_<value> type;
  typedef mpl::bool_< BOOST_MPL_AUX_VALUE_WKND(helper)::value > type;


Should we use adopt this implementation in mpl itself? Will it break with
some compiler?


Fernando Cacciola

Boost list run by bdawes at, gregod at, cpdaniel at, john at