Ich habe gerade den Wikipedia-Artikel gelesen C11die neue Version des C-Standards, die im Dezember 2011 veröffentlicht wurde, und ich sah, dass eine der hinzugefügten Funktionen “typgenerische Ausdrücke” war:
Geben Sie generische Ausdrücke mit dem ein _Generic Stichwort. Beispielsweise das folgende Makro cbrt(x) wird übersetzt in cbrtl(x), cbrt(x) oder cbrtf(x)
je nach art x:
#define cbrt(X) _Generic((X), long double: cbrtl, \
default: cbrt, \
float: cbrtf)(X)
Das sieht für mich ziemlich schrecklich aus – wenn sie die Sprache sowieso ändern, warum nicht einfach eine Funktionsüberladung wie in C++ hinzufügen?
C hat einen Namensraum für externe Symbole und wendet die ODR (One Definition Rule) so an, dass zwei extern Objekte mit demselben Namen in zwei Übersetzungseinheiten müssen dieselbe Definition haben.
Obwohl es möglich ist, eine C-ABI zu erstellen, die das Überladen unterstützt, ist die Hauptstärke von C die Einfachheit der ABI. Auf fast allen Plattformen ist “die” ABI die C-ABI, und sie spielt unabhängig von der Quellsprache eine gewisse Rolle bei der Ausführung. Dies würde verloren gehen, wenn Symbole Typinformationen enthalten müssten.
TGE (wie es von der Bibliothek verwendet wird) ist nur eine manuell betriebene Version der Namensverfälschung. Es erledigt (oder wird es irgendwann in möglicherweise sehr ferner Zukunft tun) die Aufgabe, die es erfüllen muss, um es zu ermöglichen typedef Deklarationen zur Steuerung der Generierung mathematisch intensiver innerer Schleifen. Leute, die die Funktionen einer Sprache wie C++ benötigen, sollten auf C++ portieren.
Wahrscheinlich, weil dies eine Namensverstümmelung erfordern würde und _Generic zur Kompilierzeit vollständig aufgelöst werden kann. Wie auch immer, wenn Sie es mit generischer Programmierung ernst meinen, sollten Sie sich nicht mit C beschäftigen.
– Katze Plus Plus
7. Januar 2012 um 23:33 Uhr
Das Überladen von Funktionen würde wahrscheinlich in praktisch allen Implementierungen zu einem großen Abwärtskompatibilitätsproblem führen (denken Sie daran, wie C-Laufzeiten/Linker/Lader Symbole behandeln).
– Nr
7. Januar 2012 um 23:36 Uhr
@CatPlusPlus: Das Zulassen des Überladens für als “inline” deklarierte Funktionen hätte 99% des Vorteils des allgemeinen Überladens von Funktionen erbracht, ohne Probleme mit der Namensverfälschung. Selbst wenn man in der Lage sein möchte, eine überladene Funktion von anderen Modulen aufzurufen, könnte man einfach überladene “Inline”-Funktionen in die Header-Datei aufnehmen, die dann anders benannte Funktionen für verschiedene Parametertypen aufrufen würden. Die Namen der Funktionen würden in der Header-Datei angegeben, sodass kein Compiler-spezifisches Mangling erforderlich wäre. Hätte es damit ein Problem gegeben?
– Superkatze
7. Januar 2012 um 23:51 Uhr
@supercat: Außer
inlinegarantiert nicht (und sollte es auch nicht) tatsächliches Inlining (außerdem ist es eine Optimierung, die deaktiviert werden kann, und Sie können Code nicht beschädigen, wenn sich die Optimierungseinstellungen ändern)._Genericist eine Möglichkeit, Verstümmelungen zu vermeiden, indem eine geschlossene Menge bereits verstümmelter Namen erstellt wird.– Katze Plus Plus
7. Januar 2012 um 23:59 Uhr
@CatPlusPlus: Es ist wahr, dass ein Compiler frei ist, eine tatsächlich verknüpfte Instanz einer Funktion zu generieren, anstatt sie zu inlinen, aber mein Verständnis war, dass der Compiler in solchen Fällen “inline” in “statisch” konvertiert und somit eine als “inline” deklarierte Funktion ” ist nur von dem Modul aus aufrufbar, in dem es deklariert ist. Da solche Funktionen keine interne Verknüpfung haben, könnten Compiler mit dem Namen alles machen, was sie wollen, vorausgesetzt, er passt zu nichts in einem anderen Modul. Ein Compiler könnte auf Wunsch einfach GUIDs (ohne Satzzeichen) zuweisen – es wäre wirklich egal.
– Superkatze
8. Januar 2012 um 0:09 Uhr