Right now on Intel 11.1 (and perhaps others), the C++0X lambdas are
not compatible with the result_of protocols.  Since the lambdas are
monomorphic, a nested result_type typedef on the compiler generated
functor would do the trick.  While I would like to use newer methods
of detecting return types, a lot of older code (especially in the
boost and std libraries) relies on std::tr1::result_of or
boost::result_of.

Is it reasonable for a nested typedef to be in the standard or at
least in common practice?  I have submitted a feature request to intel.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mar 8, 8:58 pm, Jesse Perla <jessepe...@gmail.com> wrote:
> Right now on Intel 11.1 (and perhaps others), the C++0X lambdas are
> not compatible with the result_of protocols.  Since the lambdas are
> monomorphic, a nested result_type typedef on the compiler generated
> functor would do the trick.  While I would like to use newer methods
> of detecting return types, a lot of older code (especially in the
> boost and std libraries) relies on std::tr1::result_of or
> boost::result_of.
>
> Is it reasonable for a nested typedef to be in the standard or at
> least in common practice?  I have submitted a feature request to intel.

IMO such a typedef should not be provided, if the is solvable by
other means, because lambdas are a pure core language
thing (You could argue that the same is true for
std::initializer_list's,
so this is a weak position against that proposal).

Second, the C++0x definition of result_of is *not* based on
the existence of a result_type analysis. In fact, it is near to
consense
that the specification will be based on a single decltype definition,
see

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1225
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1255
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1270

Even in the presence of the suggested conversion of lambdas to
a function pointer with the corresponding signature as of

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3043.html

there should be no ambiguity problems. Given above definition
of result_of the following just works (assume that LambdaClass1
and LambdaClass0 are the corresponding closure class types):

struct LambdaClass1 {
 int operator()(double) const;
 typedef int (*PF)(double);
 operator PF() const;
};

static_assert(std::is_same<result_of<LambdaClass1(double)>::type,
int>::value, "Ouch");
static_assert(std::is_same<result_of<LambdaClass1&(double)>::type,
int>::value, "Ouch");
static_assert(std::is_same<result_of<LambdaClass1(double&)>::type,
int>::value, "Ouch");
static_assert(std::is_same<result_of<LambdaClass1&(double&)>::type,
int>::value, "Ouch");
static_assert(std::is_same<result_of<LambdaClass1(int)>::type,
int>::value, "Ouch");
static_assert(std::is_same<result_of<LambdaClass1&(const int&)>::type,
int>::value, "Ouch");
static_assert(std::is_same<result_of<LambdaClass1&(int&)>::type,
int>::value, "Ouch");

struct LambdaClass0 {
 int operator()() const;
 typedef int (*PF)();
 operator PF() const;
};

static_assert(std::is_same<result_of<LambdaClass0()>::type,
int>::value, "Ouch");
static_assert(std::is_same<result_of<LambdaClass0&()>::type,
int>::value, "Ouch");

HTH & Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 8 Mrz., 20:58, Jesse Perla <jessepe...@gmail.com> wrote:
> Right now on Intel 11.1 (and perhaps others), the C++0X lambdas are
> not compatible with the result_of protocols. Since the lambdas are
> monomorphic, a nested result_type typedef on the compiler generated
> functor would do the trick.  While I would like to use newer methods
> of detecting return types, a lot of older code (especially in the
> boost and std libraries) relies on std::tr1::result_of or
> boost::result_of.
>
> Is it reasonable for a nested typedef to be in the standard or at
> least in common practice?  I have submitted a feature request to intel.

I'm not sure what you're asking here. If you expect lambdas to work it
is IMHO also reasonable to expect that the compiler supports enough
"magic" (i.e. decltype) to make result_of work for any class-type
functor regardless of whether a nested typedef for result_type exists
or not. C++0x will include its own result_of in the std namespace
which will probably be defined in terms of decltype:

    template<typename Fun, typename... Args>
    class result_of<Fun(Args...)> {
    public:
       typedef decltype( declval<Fun>() (declval<Args>()...) ) type;
    };

See the end of library issue #1255:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1255

For TR1 implementers it makes sense to "backport" this to TR1 so that
some other pre-C++0x template code (which makes use of
std::tr1::result_of) can deal with lambdas as well -- without forcing
compilers to generate nested typedefs for lambdas.

Cheers,
SG


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Thanks for replying Daniel and SG.
On Mar 9, 6:23 am, Daniel Kr   gler <daniel.krueg...@googlemail.com>
wrote:
> Second, the C++0x definition of result_of is *not* based on
> the existence of a result_type analysis. In fact, it is near to
> consense that the specification will be based on a single decltype definition,

Certainly, and it makes plenty of sense in a full C++0X implementation
with the
new standard library.


On Mar 9, 6:24 am, SG <s.gesem...@gmail.com> wrote:
> For TR1 implementers it makes sense to "backport" this to TR1 so that
> some other pre-C++0x template code (which makes use of
> std::tr1::result_of) can deal with lambdas as well -- without forcing
> compilers to generate nested typedefs for lambdas.

Yes, this is what I am talking about.  I understand that
decltype(F(x)), etc. should be used,
but there is a huge amount of code out there using boost::result_of
and std::tr1::result_of
that is breaking right now with C++0X lambdas.  Intel support told me
that they didn't believe there
was anything in the standard that lambdas should work with existing
result_of, and I wanted to check
in to see if this was the case or if there was any sort of back
portability that could be attained.

Sounds like the answer is that I need to wait for a more complete
implementation with a synced
up standard library, etc, and patch boost::result_of to use new
mechanisms when they come out.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]