From: David Abrahams (dave_at_[hidden])
Date: 2004-01-09 21:45:05
"Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:
> 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"
It can, but it's not an error to supply the ::type.
> However, that code did pass many of the other compilers, so that "::type"
> does exist in some cases.
The type should always exist.
> Is this a bug in the VC7.1 version of "is_same"? That is, was it intended to
> have "::type"?
Is it a bug in the compiler? We can't know until you post a
reproducible test case.
> 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
We can't know until you post a reproducible test case ;-)
> 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_STATIC_CONSTANT(bool, value =
> 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?
I don't think so. Integral constants shouldn't be required to have a
value_type IMO. Anyway, it's unclear to me why your implementation
would solve any problems. Can you explain it?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk