Como especifico um ponteiro para uma função sobrecarregada?

Eu quero passar uma função sobrecarregada para o std::for_each()algoritmo. Por exemplo,

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

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

Eu esperaria que o compilador resolvesse f()pelo tipo de iterador. Aparentemente, ele (GCC 4.1.2) não faz isso. Então, como posso especificar qual f()eu quero?

Você pode usar static_cast<>()para especificar qual fusar de acordo com a assinatura da função implícita no tipo de ponteiro de função:

// 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)); 

Ou, você também pode fazer isso:

// 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

Se ffor uma função membro, você precisará usar mem_fun, ou para o seu caso, a solução apresentada neste artigo do Dr. Dobb .

Lambdas para o resgate! (observação: C ++ 11 obrigatório)

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

Ou usando decltype para o parâmetro lambda:

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

Com lambdas polimórficas (C ++ 14):

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

Ou desambique removendo a sobrecarga (funciona apenas para funções gratuitas):

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

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

Por que isso não funciona?

Eu esperaria que o compilador resolvesse f()pelo tipo de iterador. Aparentemente, (gcc 4.1.2) não faz isso.

Seria ótimo se fosse esse o caso! No entanto, for_eaché um modelo de função, declarado como:

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

A dedução de modelo precisa selecionar um tipo para UnaryFunctionno ponto da chamada. Mas fnão tem um tipo específico - é uma função sobrecarregada, existem muitos fs com tipos diferentes. Atualmente, não existe uma maneira de for_eachauxiliar o processo de dedução de modelo, indicando o que fele deseja; portanto, a dedução de modelo simplesmente falha. Para que a dedução do modelo seja bem-sucedida, você precisa trabalhar mais no site de chamada.

Solução genérica para corrigi-lo

Entrando aqui alguns anos e C ++ 14 depois. Em vez de usar a static_cast(que permitiria a dedução do modelo com êxito "corrigindo" o que fqueremos usar, mas requer que você execute manualmente a resolução de sobrecarga para "corrigir" a correta)), queremos fazer o compilador funcionar para nós. Queremos chamar falguns argumentos. Da maneira mais genérica possível, é isso:

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

É muito difícil digitar, mas esse tipo de problema surge irritantemente com frequência, para que possamos apenas envolvê-lo em uma macro (suspiro):

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

e então apenas use:

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

Isso fará exatamente o que você deseja que o compilador faça - execute a resolução de sobrecarga no fpróprio nome e faça a coisa certa. Isso funcionará independentemente de fser uma função livre ou uma função de membro.

Não para responder à sua pergunta, mas eu sou o único que acha

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

mais simples e mais curto que a for_eachalternativa sugerida por in silico neste caso?

O problema aqui parece não ser a resolução de sobrecarga, mas na verdade a dedução dos parâmetros do modelo . Embora a excelente resposta do @In silico resolva um problema ambíguo de sobrecarga em geral, parece que a melhor solução ao lidar com std::for_each(ou similar) é especificar explicitamente seus parâmetros de modelo :

// 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" );
}

Se você não se importa em usar o C ++ 11, aqui está um ajudante inteligente que é semelhante (mas menos feio que) ao elenco estático:

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; }

(Funciona para funções-membro; deve ser óbvio como modificá-lo para funcionar em funções independentes, e você deve poder fornecer as duas versões e o compilador selecionará a correta para você.)

Agradecemos a Miro Knejp por sugerir: consulte também https://groups.google.com/a/isocpp.org/d/msg/std-discussion/rLVGeGUXsK0/IGj9dKmSyx4J .