Jak określić wskaźnik do przeciążonej funkcji?

Chcę przekazać przeciążoną funkcję do std::for_each()algorytmu. Na przykład,

class A {
    void f(char c);
    void f(int i);

    void scan(const std::string& s) {
        std::for_each(s.begin(), s.end(), f);
    }
};

Spodziewałbym się, że kompilator rozwiąże f()typ iteratora. Najwyraźniej to (GCC 4.1.2) tego nie robi. Jak więc mogę określić, co f()chcę?

Możesz użyć, static_cast<>()aby określić, którego fużyć zgodnie z sygnaturą funkcji implikowaną przez typ wskaźnika funkcji:

// Uses the void f(char c); overload
std::for_each(s.begin(), s.end(), static_cast<void (*)(char)>(&f));
// Uses the void f(int i); overload
std::for_each(s.begin(), s.end(), static_cast<void (*)(int)>(&f)); 

Możesz też to zrobić:

// The compiler will figure out which f to use according to
// the function pointer declaration.
void (*fpc)(char) = &f;
std::for_each(s.begin(), s.end(), fpc); // Uses the void f(char c); overload
void (*fpi)(int) = &f;
std::for_each(s.begin(), s.end(), fpi); // Uses the void f(int i); overload

Jeśli fjest to funkcja członkowska, musisz użyć mem_funlub w swoim przypadku użyć rozwiązania przedstawionego w tym artykule dr Dobba .

Jagnięta na ratunek! (uwaga: wymagany C ++ 11)

std::for_each(s.begin(), s.end(), [&](char a){ return f(a); });

Lub używając decltype dla parametru lambda:

std::for_each(s.begin(), s.end(), [&](decltype(*s.begin()) a){ return f(a); });

Z lambdami polimorficznymi (C ++ 14):

std::for_each(s.begin(), s.end(), [&](auto a){ return f(a); });

Lub ujednoznacznij, usuwając przeciążenie (działa tylko w przypadku bezpłatnych funkcji):

void f_c(char i)
{
    return f(i);
}

void scan(const std::string& s)
{
    std::for_each(s.begin(), s.end(), f_c);
}

Dlaczego to nie działa

Spodziewałbym się, że kompilator rozwiąże f()typ iteratora. Najwyraźniej to (gcc 4.1.2) tego nie robi.

Byłoby wspaniale, gdyby tak było! Jednak for_eachjest to szablon funkcji zadeklarowany jako:

template <class InputIterator, class UnaryFunction>
UnaryFunction for_each(InputIterator, InputIterator, UnaryFunction );

Odliczenie szablonowe należy wybrać typ UnaryFunctionw momencie połączenia. Ale fnie ma określonego typu - jest to przeciążona funkcja, istnieje wiele ftypów, z których każdy ma inny typ. Obecnie nie ma sposobu, for_eachaby wspomóc proces odliczania według szablonu, określając, czego fchce, więc odliczenie szablonowe po prostu się nie udaje. Aby odliczenie szablonu zakończyło się sukcesem, musisz wykonać więcej pracy w witrynie wezwania.

Ogólne rozwiązanie tego problemu

Wskoczę tutaj kilka lat i C ++ 14 później. Zamiast używać a static_cast(co pozwoliłoby na pomyślną dedukcję szablonu przez „naprawienie”, którego fchcemy użyć, ale wymaga ręcznego rozwiązania problemu z przeciążeniem, aby „naprawić” poprawne), chcemy, aby kompilator działał za nas. Chcemy wywołać fkilka argumentów. W najbardziej ogólny sposób jest to:

[&](auto&&... args) -> decltype(auto) { return f(std::forward<decltype(args)>(args)...); }

To dużo do pisania, ale tego rodzaju problem pojawia się irytująco często, więc możemy po prostu zawrzeć to w makro (westchnienie):

#define AS_LAMBDA(func) [&](auto&&... args) -> decltype(func(std::forward<decltype(args)>(args)...)) { return func(std::forward<decltype(args)>(args)...); }

a potem po prostu go użyj:

void scan(const std::string& s) {
    std::for_each(s.begin(), s.end(), AS_LAMBDA(f));
}

Zrobi to dokładnie to, co chcesz, aby zrobił kompilator - wykona rozwiązanie przeciążenia na fsamej nazwie i po prostu zrób to, co trzeba. Będzie to działać niezależnie od tego, czy fjest to funkcja wolna, czy funkcja składowa.

Nie odpowiadam na twoje pytanie, ale czy tylko ja znajduję

for ( int i = 0; i < s.size(); i++ ) {
   f( s[i] );
}

prostsza i krótsza niż for_eachalternatywa sugerowana przez in silico w tym przypadku?

Wydaje się, że problemem tutaj nie jest rozwiązanie przeciążenia, ale w rzeczywistości dedukcja parametrów szablonu . Chociaż doskonała odpowiedź od @In silico rozwiąże ogólnie niejednoznaczny problem przeciążenia, wydaje się, że najlepszym rozwiązaniem w przypadku std::for_each(lub podobnego) rozwiązania jest jawne określenie parametrów szablonu :

// Simplified to use free functions instead of class members.

#include <algorithm>
#include <iostream>
#include <string>

void f( char c )
{
  std::cout << c << std::endl;
}

void f( int i )
{
  std::cout << i << std::endl;
}

void scan( std::string const& s )
{
  // The problem:
  //   error C2914: 'std::for_each' : cannot deduce template argument as function argument is ambiguous
  // std::for_each( s.begin(), s.end(), f );

  // Excellent solution from @In silico (see other answer):
  //   Declare a pointer of the desired type; overload resolution occurs at time of assignment
  void (*fpc)(char) = f;
  std::for_each( s.begin(), s.end(), fpc );
  void (*fpi)(int)  = f;
  std::for_each( s.begin(), s.end(), fpi );

  // Explicit specification (first attempt):
  //   Specify template parameters to std::for_each
  std::for_each< std::string::const_iterator, void(*)(char) >( s.begin(), s.end(), f );
  std::for_each< std::string::const_iterator, void(*)(int)  >( s.begin(), s.end(), f );

  // Explicit specification (improved):
  //   Let the first template parameter be derived; specify only the function type
  std::for_each< decltype( s.begin() ), void(*)(char) >( s.begin(), s.end(), f );
  std::for_each< decltype( s.begin() ), void(*)(int)  >( s.begin(), s.end(), f );
}

void main()
{
  scan( "Test" );
}

Jeśli nie masz nic przeciwko używaniu C ++ 11, oto sprytny pomocnik, który jest podobny do (ale mniej brzydki) rzutowania statycznego:

template<class... Args, class T, class R>
auto resolve(R (T::*m)(Args...)) -> decltype(m)
{ return m; }

template<class T, class R>
auto resolve(R (T::*m)(void)) -> decltype(m)
{ return m; }

(Działa dla funkcji składowych; powinno być oczywiste, jak zmodyfikować go, aby działał dla funkcji wolnostojących, a powinieneś być w stanie zapewnić obie wersje, a kompilator wybierze odpowiednią dla Ciebie.)

Podziękowania dla Miro Knejp za sugestię: zobacz także https://groups.google.com/a/isocpp.org/d/msg/std-discussion/rLVGeGUXsK0/IGj9dKmSyx4J .