Re: [boost] [utility] result_of and lambda patch

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2007-03-20 17:30:29

On 3/20/07, Eric Niebler <eric_at_[hidden]> wrote:
> Giovanni Piero Deretta wrote:
> >
> > What about doing both? Result_of would implement (maybe undocumented
> > and deprecated) sig support. Lambda would implement and document both
> > result and sig, deprecating the latter. In a release or two, both
> > lambda and result_of would drop sig support. The users should have
> > plenty of time for updating their code.
>
>
> I'm not sure this is a good idea. I haven't looked at the patch to mpl's
> has_xxx code to make it detected nested class templates, but I wonder
> how portable it is to older compilers. I know from experience how
> finicky the result_of implementation is, and getting this to work on all
> the compilers result_of currently works on would be a difficult
> (impossible?) task. I'm willing to be proved wrong, however.

You're right that detecting nested templates may not be portable to
older compilers. However, my result_of patch doesn't require full
nested template detection support.

My patch for has_template_xxx (I didn't try to change has_xxx to
support both nested classes and template classes) provides
functionality on unsupported compilers the same way has_xxx does.
has_template_xxx::value is always false on unsupported compilers (or a
user supplied default).

In my patch for result_of, lack of support for has_template_xxx is
handled by checking BOOST_MPL_CFG_NO_HAS_TEMPLATE_XXX. In this case,
partial specializations for lambda::lambda_functor are provided so
that lambda expressions can be supported, even though user defined
functors using sig<> cannot. result_of already requires that the
compiler support partial specialization. So, to the best of my
knowledge, this doesn't add an additional limitation on the number of
compilers result_of can work on.

Daniel