[boost] mpl, type_traits and VC7.1

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

Hi,

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

(1)
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"?

(2)
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
                          ,BOOST_MPL_AUX_VALUE_WKND(T1)::value
                          ,T2_val_type
                          ,BOOST_MPL_AUX_VALUE_WKND(T2)::value
                         > helper ;

  BOOST_STATIC_CONSTANT(bool, value =
BOOST_MPL_AUX_VALUE_WKND(helper)::value );

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

};

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

TIA

Fernando Cacciola
SciSoft