[Boost-users] Re: Re: Re: Re: Re: result_of tutorial

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-03-17 23:55:17

"Ian McCulloch" <ianmcc_at_[hidden]> wrote
> Arkadiy Vertleyb wrote:
> > template<class T>
> > T make();
> >
> > template <class T>
> > BOOST_TYPEOF_TPL(make<std::negate<T> >()(T()))
> > operator-(T const& x)
> > {
> >     return std::negate<T>()(x);
> > }
>
> This looks very attractive, and I'll probably und up using it somewhere;
but
> in the particular application I'm working on, something like result_of
(but
> allows SFINAE) will do fine.  I guess its just a matter of what changes
> I'll need to make when we get decltype.  With the result_of approach I
> could get rid of the nested result<> structs and/or result_of
> specializations, with the BOOST_TYPEOF approach I could simplify the
> forwarding function declarations.  I'm not sure what is the better
> tradeoff.

We have BOOST_LVALUE_TYPEOF(), which attempts to mimique decltype.  It's not
*quite* decltype, however :-(

Also, where built-in typeof exists, we forward to it, so you don't have to
pay for all the emulation stuff.

The main drawbacks are:

1) The need to register user-defined types/templates (although it's pretty
simple);
2) Potential ODR non-conformance, because of automatic ID generation/use of
unnamed namespace (although it doesn't seem to show up in any compilers we
tested with, and we specifically try to cause it);
3) Slower compile times if complicated types are used;
4) Some (workaroundable) problems with standard iterator registration in
Dinkumware STL (because of nested classes/non-deduced context)

If you can live with the above four, I believe our typeof emulation is worth
trying.

(Please be awere, however, that the above code I provided may not compile in
the current submission version, if you use VC71.  It is subject to ETI bug
workaround that I found trying to adapt your code, so thanks!  It works with
my local version that I plan to upload sometime before the review.  If you
do need it sooner, please let me know)

Regards,
Arkadiy