Mein Fall ist ziemlich einfach: Ich möchte, dass mein C ++ - Programm Unix-Signale verarbeitet. Dazu stellt glibc eine Funktion in signal.h namens sigaction bereit, die erwartet, dass sie einen Funktionszeiger als zweites Argument erhält.
Meine Frage ist: Ist der extern "C" Linkbezeichner notwendig?
Bonusfrage: Kann uponSignal static deklariert werden?
Meine Frage ist: Ist der
extern "C"Linkbezeichner notwendig?
Für maximale Portabilität, ja; Der C ++ - Standard garantiert nur die Interoperabilität mit C über die Funktionen extern "C" .
Praktisch, nein; Die meisten sinnvollen ABIs (einschließlich des von glibc verwendeten GNU ABI) verwenden die gleiche Aufrufkonvention für C- und C ++ - Nichtmitgliedsfunktionen (und statische Mitglieder), sodass extern "C" nur benötigt wird, um den Funktionsnamen zwischen Sprachen zu teilen.
Bonusfrage: Kann
uponSignalals statisch deklariert werden?
Ja. Die externe Verknüpfung wird nur benötigt, um von anderen Übersetzungseinheiten namentlich auf die Funktion zuzugreifen; Es ist nicht notwendig, die Funktion über einen Funktionszeiger aufzurufen.
extern C ist nur notwendig, wenn Sie Ihre Symbole aus Ihrer Binärdatei exportieren oder sie aus einer anderen Binärdatei importieren (normalerweise in beiden Fällen eine gemeinsam genutzte Bibliothek), um Namensfehlern zu vermeiden.
Dies ist nicht der Fall. Sie verknüpfen uponSignal nicht über verschiedene Binärdateien, so dass Sie extern C nicht benötigen. Sie übergeben lediglich die Adresse Ihrer Funktion an sigaction von einer Funktion, die die Adresse von uponSignal bereits kennt, da sie (anscheinend) Teil derselben Übersetzungseinheit oder mindestens der gleichen Binärdatei sind.
Bonusfrage: Kann
uponSignalalsstaticdeklariert werden?
Sicher, wenn du willst. uponSignal benötigt sowieso keine externe Verknüpfung.