[boost] Re: Re: Re: Formal Review in progress

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-05-28 07:54:47

"Peder Holt" <peder.holt_at_[hidden]> wrote

> On 5/28/05, Arkadiy Vertleyb <vertleyb_at_[hidden]> wrote:
> > "Peder Holt" <peder.holt_at_[hidden]> wrote
> >
> > > I did some tests on VC8 beta, and it compiles the testcase in half the
> > > time compared to the present implementation of typeof_impl. As far as
> > > I have been able to test, it also works around the compiler bug for
> > > VC8 discussed earlier.
> > >
> > > Here is a more detailed sketch of the proposed solution:
> > >
> > > namespace boost {namespace type_of{
> > >     template<typename T>
> > >     struct encode_result {
> > >         typedef typename encode_type<BOOST_TYPEOF_VECTOR(0)<>,
> > > T>::type encoded_type;
> > >         typedef typename mpl::size<encoded_type>::type size;
> > >         char (&value0)[...];
> > >         char (&value1)[...];
> > >         char (&value2)[...];
> > >         ...
> > >         char (&value50)[...];
> > >     };
> > >
> > >     template<class T>
> > >     encode_result<T> typeof_result(const T&);
> > > }}
> > > #define BOOST_TYPEOF_AT(n, expr)
> > > sizeof(boost::type_of::typeof_result(expr).BOOST_PP_CAT(value,n))
> >
> > Interesting... Let me guess:
> >
> > char(&value2)[mpl::at<encode<T>::type, mpl::int<(2 < size) ? 2 : 0>
> > >::type::value]; //?
>
> Yep :)
>
>         char(&value2)[mpl::at<encoded_type,mpl::int_<(2 < size::value)
> ? 2 : 0>
> >::type::value];

Than there is no magic here :-)

You just re-introduced the simple type optimization I removed to workaround
the vc8 problem.  Cutting performance in half was the result I got.
Apparently in this simpler context vc8 is able to handle this.

This workaround is much better than mine because it doesn't degrade vc8
preformance.  And it might be better than the original (before workaround)
solution in terms of portability -- other compilers might have the same
problem vc8 has.  One thing -- we might consider a function template instead
of preprocessor-generated values...

Althouth I believe this change _should_ be applied, along with the change
that allows to remove _TPL, let's not make these changes now, and consider
this more carefully after the review.

Regards,
Arkadiy