C++ - <Unresolved Overloaded Function Type>

How do I resolve this unresolved overloaded function type error when using std::function?

The error tells you that there are two potential overloads that could be used, and the compiler cannot decide for you. On the other hand, you can determine which one to use by using a cast:

typedef const char *(*func_ptr)( shader::FUNC );
register_enum< shader::FUNC >( L, "functions", (func_ptr)shader::to_cstring );

Or without the typedef (in a harder to read one-liner):

register_enum< shader::FUNC >( L, "functions", 
             (const char *(*)( shader::FUNC ))shader::to_cstring );

^*Note that in function signatures, the top-level const gets removed.

The next question is why did the compiler not find the appropriate overload by itself? The problem there is that in the call to register_enum you pass the type of the enum, and that determines the type of the std::function to be std::function< const char* ( shader::FUNC ) >, but std::function has a templated constructor, and before trying to infer the type of the argument to the constructor, the compiler must know which overload you want to use.

no matching function for call to unresolved overloaded function type

My guess is that the constructor of std::thread cannot resolve which overload of fun you're trying to call. No idea why though.

Having only one version of fun such as

template <typename T, typename sem>
void fun(const std::string&, std::shared_ptr<sem>)
{
    ...
}

Allows you to construct t1 fine (but t2 will obviously fail).

A workaround is to pass a lambda instead, such as:

std::thread t3([&](){fun<data, sem>(d, "works again", std::make_shared<sem>());});
std::thread t4([&](){fun<data, sem>("this too", std::make_shared<sem>());});

Unresolved overloaded function type in std::transfrom

I don't want to believe that the asker didn't know they are defining two functions with the same name degrees, so I'll give another shade to my answer.

How is it possible, in this call

std::transform(val.begin(), val.end(), std::back_inserter(out), degrees);

that degrees is not known? I mean, std::transform should try to apply degrees to each element in val, and since each of those elements is a double, isn't it obvious that transform should make use of the first overload, the one which takes a double?

As convincing as this motivation might be, though, it would require the compiler to delay/defer the decision of what degrees should be called to the moment it's actually called, i.e. not at the call site of std::transform, but inside std::transform (specifically, when evaluating the expression unary_op(*first1++) in this possible implementation on the cppreference doc page).

This is simply not possible, as the rules are that the compiler must know at the call site of a function what its arguments are. With reference to the example, at the call site of std::transform the compiler has no idea which of the overloads of degree is needed.

One way around is to wrap degrees in a function object with overloaded operator(), as suggested by 463035818_is_not_a_number; doing so, the object degrees would be known at std::transform call site, and only inside std::transform, at the call site of the object's operator() would the compiler have to choose between the overloads of operator().

Unresolved overloaded function type in gcc

Yes, this is supposed to be a bug of gcc, which has not been fixed even in gcc 10.0.1.

It seems gcc fails to handling this case when specifying the return type with placeholder type specifiers like auto and decltype(auto). If you specify the return type as T it would work fine.

C++ basics: unresolved overloaded function type

&class1::functionB is a pointer-to-member-function, not a pointer-to-function. Its type is void (class1::*)(void), not void (*)(void), as expected by the onRequest method. It means that to call this pointer-to-member-function, it is required to have the instance as well (class1*).

If the class1 is a singleton, the easiest way to solve this is probably making functionB a static member or simply a non-member function (not inside any class).

If class1 cannot be assumed singleton, then the library must have a way to pass a context pointer (usually void*) along the pointer-to-function and this context is a parameter of the callback function. You should pass this as the context and a pointer to a wrapper function, like the following:

void wrapper_for_class1_functionB(void* context)
{
    static_cast<class1*>(context)->functionB();
}

void class1::functionA(void)
{
    Wire.onRequest(&wrapper_for_class1_functionB, this);
}

error: invalid operands of types 'unresolved overloaded function type' and 'int' to binary 'operator' if(min max)

You are hiding (shadowing) the std::min and std::max functions by the local declarations of int max and int min. However, this shadowing only happens in the local scope, where these variables are declared.

When you leave the scope, the outer name becomes visible again:

        int max=0;                  // <-- Here max hides std::max
        for(int i=0; i<n-k; i++)
        {
            int min=a[i];          // <-- Here min hides std::min
            for(int j=0; j<k; j++)
            {
                if(a[i+j]<min)
                {
                    min=a[i+j];
                }
            }
        }                       // <-- But here the local min goes away again

       if(min > max)            // <-- And here min is std::min, a function

So the compiler believes that min > max is to compare an int to a function template. And it cannot see how to do that.

This is one of the reasons why using using namespace std; is considered not a good idea.

---

Related Topics