Warum wird extern "C" mit gemeinsamer Objektbibliothek zur Laufzeit verwendet?

Question

1. habe ich in einem C++ Programm, die dlfcn Bibliothek zum dynamischen verwendet wird Verknüpfung mit einer gemeinsamen Objekt-Bibliothek durch den Benutzer des C gewählt ++ Programms während der Laufzeit, und für Funktionen in der gewählten gemeinsamen Objekt-Bibliothek über dlsym() Aufruf und andere Funktionen in dlfcn.

   • Angenommen, der Benutzer eine Objektbibliothek x.so während der Laufzeit aufgerufen geteilt wählt. x.so wurde aus einer cpp-Datei mit den Definitionen der Funktionen in extern "C" kompiliert. Ein Kommentar in der cpp-Datei sagt, dass die Verwendung von extern "C" ist wichtig, aber ohne weitere Erklärung, und ich frage mich warum?

   • Ist es richtig, dass hier nur C++ - Code und kein C-Code beteiligt ist? So ist extern "C" nicht unbedingt nur verwendet, wenn C und C++ zusammen Code mischen?

   • Ob die dlfcn Bibliothek statisch oder dynamisch mit dem C++ - Programm verknüpft ist, ist für die obigen Fragen wichtig?

2. nun zu einem einfacheren Fall zu vergleichen, wo die gemeinsame Objekt-Bibliothek viel früher als Laufzeit bekannt ist, und der Autor der C++ Programm gibt es in dem C++ Programm ohne dlfcn zu verwenden, bevor es kompilierst, und dann verknüpft die gemeinsam genutzte Objektbibliothek und das C++ - Programm während der Laufzeit dynamisch. Ist in diesem Fall in der cpp Datei, die in die Shared Object Library kompiliert wurde, `extern 'C noch notwendig?

Danke.

Answer 1

extern "C" ändert die Verknüpfung und wirkt sich auf Namensfehlern aus. Siehe What is name mangling, and how does it work?

Ohne es werden exportierte Namen in das kompilierte Objekt normalerweise gemangelt. Das bedeutet, dass sie nicht von C aus verwendet werden können. Es bedeutet auch, dass das Nachschlagen über dlsym() die Verwendung des Mangled-Namens erfordert.

Ist es richtig, dass hier nur C++ - Code und kein C-Code beteiligt ist? Wird also extern "C" nicht unbedingt beim Mischen von C- und C++ - Code verwendet?

Es ist nicht klar, was Sie hier meinen. Wenn Sie C++ kompilieren, ist nur C++ - Code in diesem Stadium beteiligt. Wenn Sie dann in irgendeiner Weise mit einem in C geschriebenen Modul verknüpfen, dann ist C beteiligt. Wenn Sie eine externe C-Bibliothek oder ein Programm benötigen, um eine Verbindung zu Ihren C++ - definierten Funktionen herzustellen, müssen Sie sie als extern "C" deklarieren.

Ob die Bibliothek dlfcn statisch oder dynamisch mit dem Programm C++ verknüpft ist, ist für die obigen Fragen wichtig?

Nein (vielleicht sollten Sie erklärt haben, warum Sie denken, dass es wichtig sein könnte).

vergleichen nun zu einem einfacheren Fall, in dem die gemeinsamen Objekt-Bibliothek bekannt ist, viel früher als Laufzeit, und der Autor des C++ Programms gibt es in dem C++ Programm ohne vor dem Kompilieren es mit dlfcn, und dann verbindet dynamisch die Shared-Object-Bibliothek und das C++ - Programm zur Laufzeit. Ist in diesem Fall "extern" C "noch in der cpp-Datei notwendig, die in die Shared Object Library kompiliert wurde?

Es ist notwendig, dass die deklarierte Verknüpfung der Symbole in den beiden C++ - Modulen konsistent ist. Natürlich könnten Sie extern "C" entfernen, wenn die Module beide C++ sind. Aber wenn ein Modul das Symbol als extern "C" deklariert, dann muss das andere auch.