Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-01-09 21:45:05


"Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:

> 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"

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.

> (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

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
> ,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?

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