See comments in the source code, and more importantly document it in the doc for writing functors, and add a unit test.
As mentioned in Bug 1006, we should also decide where using result_of is necessary, at all. Essentially, I only see binaryExpr(other, Func) and unaryExpr(Func) (from plugins/CommonCwiseBinaryOps.h) where this is should be used. And as we can't really rely on TR1/C++11 to be available, probably, we should probably just check if Func::result_type exists and use ArgType0 otherwise.
Thank you for addressing the redux issue in bug 1006! Unfortunately, I'm running into similar issues with scalar types that are themselves aligned in the traits class for CWiseUnaryOp, specifically the Scalar typedef: typedef typename result_of< UnaryOp(typename XprType::Scalar) >::type Scalar; Again, passing by value results in C2719 on MSVC (2015 in my case) 32 bit.
Should be fixed by: https://bitbucket.org/eigen/eigen/commits/f2e6b911501d/ We can still wonder whether we want to support the TR1 protocol, or not? It's not really tested, and since it is not documented, I doubt that anybody is using it. Moreover, it does not work in C++11 mode.
That fixed our issue. Thank you for another quick response!
*** Bug 1279 has been marked as a duplicate of this bug. ***
There is no need to spend effort in cleaning/improving result_of anymore since we use std::result_of when available.
-- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/96.