Re: [eigen] 3.2.10 released!

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

Hi,

I've just pushed a workaround that simply bypass those tricky helpers for the built-in nullary functors. I cannot test it on gcc 4.1, but that should do the job.

gael

On Wed, Oct 5, 2016 at 7:05 PM, Thomas Klimpel <jacques.gentzen@xxxxxxxxx> wrote:

I give up, I'm unable to implement those has_binary_operator, has_unary_operator, and has_nullary_operator traits for gcc 4.1.2. None of the unbelievable tricks from boost.mpl and boost.type_traits seems to work for operator(). It is simply not possible to create an alternative resolution of the call which could avoid the compile error:

1) The obvious idea to declare a free operator()(...) is not allowed:

error: int operator()(const A&, ...) must be a nonstatic member function

​

2) The idea to derive a helper class from a class defining operator()(...) and the investigated class fails, because the overload is judged as ambiguous:
error: request for member operator() is ambiguous

3) The ingenious way boost.mpl uses to detect a named member function via "static_cast<void(*)(name)>(0)" fails, because "operator()" cannot be used as a typename:

template< typename T, typename name = aux_no_tag>
struct trait_impl : T
{
    static aux_no_tag test(void(*)(aux_no_tag));
    static aux_yes_tag test(...);
    bool value = sizeof(test(static_cast<void(*)(name)>(0)))  != sizeof(aux_no_tag) \
};

An indication that detecting operator() on old C++03 compilers (i.e. gcc 4.1.2) is not possible is that neither boost.mpl nor boost.type_traits offers this test.

Sorry for delaying the Eigen 3.3 release.