W poniższym kodzie pierwsze wywołanie foojest niejednoznaczne i dlatego nie można skompilować.
Drugi, z dodanym +przed lambdą , jest wynikiem przeciążenia wskaźnika funkcji.
#include <functional>
void foo(std::function<void()> f) { f(); }
void foo(void (*f)()) { f(); }
int main ()
{
foo( [](){} ); // ambiguous
foo( +[](){} ); // not ambiguous (calls the function pointer overload)
}
Co +tu robi notacja?
Odpowiedzi:
W +wyrażeniu +[](){}jest +operatorem jednoargumentowym . W [expr.unary.op] / 7 jest zdefiniowany w następujący sposób:
Operand
+operatora jednoargumentowego powinien mieć typ arytmetyczny, wyliczeniowy bez zakresu lub typ wskaźnika, a wynikiem jest wartość argumentu.
Lambda nie jest typu arytmetycznego itp., Ale można ją przekonwertować:
[wyr.prim.lambda] / 3
Typ wyrażenia lambda [...] jest unikalnym, nienazwanym typem klasy nieunijnej - zwanym typem zamknięcia - którego właściwości opisano poniżej.
[wyr.prim.lambda] / 6
Typ zamknięcia do lambda ekspresji bez lambda chwytania ma
publicNieskarbowychvirtualNieskarbowychexplicitconstfunkcję konwersji do wskaźnika do funkcji o tych samych typów parametrów i powrotnym dla obsługi funkcji danego typu Zamknięcie-tych. Wartość zwracana przez tę funkcję konwersji będzie adresem funkcji, która po wywołaniu ma taki sam skutek, jak wywołanie operatora wywołania funkcji typu zamknięcia.
Dlatego jednoargumentowa +wymusza konwersję do typu wskaźnika funkcji, który jest dla tej lambdy void (*)(). Dlatego typ wyrażenia +[](){}to ten typ wskaźnika funkcji void (*)().
Drugie przeciążenie void foo(void (*f)())staje się dokładnym dopasowaniem w rankingu rozpoznawania przeciążenia i w związku z tym jest wybierane jednoznacznie (ponieważ pierwsze przeciążenie NIE jest dokładnym dopasowaniem).
Lambda [](){}można przekonwertować na std::function<void()>za pomocą niejawnego edytora szablonu programu std::function, który przyjmuje dowolny typ, który spełnia wymagania Callablei CopyConstructible.
Lambda można również przekonwertować na void (*)()funkcję konwersji typu zamknięcia (patrz wyżej).
Obie są sekwencjami konwersji zdefiniowanymi przez użytkownika i mają tę samą rangę. Dlatego rozpoznawanie przeciążenia w pierwszym przykładzie zawodzi z powodu niejednoznaczności.
Zdaniem Cassio Neri, popartego argumentem Daniela Krüglera, ta jednoargumentowa +sztuczka powinna być określonym zachowaniem, tj. Można na nim polegać (patrz dyskusja w komentarzach).
Mimo to polecam użycie jawnego rzutowania na typ wskaźnika funkcji, jeśli chcesz uniknąć niejednoznaczności: nie musisz pytać SO, co się dzieje i dlaczego działa;)
operator +()do bezstanowego typu zamknięcia. Załóżmy, że ten operator zwraca coś innego niż wskaźnik do funkcji, na którą konwertuje typ zamknięcia. Wówczas zmieniłoby to obserwowalne zachowanie programu, który narusza 5.1.2 / 3. Proszę, daj mi znać, jeśli zgadzasz się z tym rozumowaniem.
operator +, ale jest to porównanie z sytuacją, w której nie ma operator +na początku. Ale nie jest określone, że typ zamknięcia nie powinien mieć operator +przeciążenia. „Implementacja może definiować typ zamknięcia inaczej niż opisano poniżej, pod warunkiem że nie zmienia to obserwowalnego zachowania programu poza [...]”, ale dodanie operatora przez IMO nie zmienia typu zamknięcia na inny niż ten, który jest „opisany poniżej”.
operator +()jest dokładnie tą opisaną przez normę. Standard pozwala implementacji na zrobienie czegoś innego niż to, co zostało określone. Na przykład dodanie operator +(). Jeśli jednak ta różnica jest zauważalna przez program, to jest to nielegalne. Kiedyś zapytałem w comp.lang.c ++. Moderowane, czy typ zamknięcia może dodać typedef dla result_typei inny typedefswymagany do dostosowania ich (na przykład przez std::not1). Powiedziano mi, że nie może, ponieważ jest to obserwowalne. Spróbuję znaleźć link.
std::bindzstd::functionobiektem, który można wywołać podobnie do funkcji lwartość.