Ich erinnere mich, dass ich vage Kommentare von einigen zuverlässigen Quellen (d. h. Ausschussmitgliedern, die in nicht offiziellen Kanälen sprechen) höre, dass C-type-generische Ausdrücke nicht zu C ++ hinzugefügt werden, weil sie nicht sein können.
Soweit ich das beurteilen kann, sind type-generic Ausdrücke im Vergleich zu C ++ - Templates und Überladen sehr begrenzt, aber es gibt kein Potential für eine Interaktion, die als Spezialfall definiert werden müsste.
Ein typengenerischer Ausdruck besteht aus einem steuernden Ausdruck und einer Reihe von "Assoziationen" zwischen Typen und Unterausdrücken. Ein Teilausdruck wird basierend auf dem statischen Typ des steuernden Ausdrucks und den für die Teilausdrücke aufgelisteten Typen ausgewählt und anstelle des TGE ersetzt. Das Matching basiert auf dem C-Konzept der Typkompatibilität, das meiner Meinung nach der C ++ - Identität von Typen mit extern linkage unter der One-Definition-Regel (ODR) entspricht.
Es wäre nett, wenn eine abgeleitete Klasse, die den Ausdruck steuert, eine Basisklassenzuordnung in C ++ auswählt, aber da C keine Vererbung hat, wird solch eine Eigenschaft für die Kreuzkompatibilität nicht benötigt. Wird dies ohnehin als Stolperstein angesehen?
Bearbeiten: Für genauere Details sieht C11 bereits vor, dass die Wertkategorie (lvalue-ness) des ausgewählten Teilausdrucks beibehalten wird, und scheint zu erfordern, dass der TGE ein konstanter Ausdruck (von was auch immer) ist Kategorie) solange alle Operanden einschließlich des steuernden Ausdrucks vorhanden sind. Dies ist wahrscheinlich ein C-Sprachdefekt. In jedem Fall definiert C ++ 14 konstante Ausdrücke im Hinblick darauf, was möglicherweise ausgewertet werden kann, und die TGE-Spezifikation besagt bereits, dass nicht ausgewählte Teilausdrücke nicht ausgewertet werden.
Der Punkt ist, dass das TGE-Prinzip der Operation so einfach zu sein scheint, dass es transplantiert werden kann, ohne dass es später Probleme gibt.
Wie für warum C ++ TGEs wären nützlich, abgesehen von der Maximierung der Schnittmenge von C und C ++, könnten sie verwendet werden, um static_if im Wesentlichen ohne die kontroverse bedingte Deklarationsfunktion zu implementieren. Ich bin kein Befürworter von static_if , aber "da ist das."
"Kann nicht sein" ist vielleicht zu stark. "Unsicher, ob es möglich ist" ist wahrscheinlicher.
Wenn diese Funktion zu C ++ hinzugefügt werden soll, sollte sie vollständig spezifiziert werden, einschließlich aller Interaktionen mit existierenden C ++ - Funktionen, von denen viele nicht mit _Generic entworfen wurden. Z.B. typeid existiert nicht in C, sollte aber in C ++ funktionieren. Können Sie einen _Generic Ausdruck als constexpr verwenden? Als Vorlagenparameter? Ist es ein lvalue ? Kann man seine Adresse nehmen und diese einem Funktionszeiger zuweisen und Überladungsauflösung bekommen? Können Sie einen Vorlagenargumentabzug vornehmen? Kannst du es mit auto benutzen? Etc.
Eine weitere Komplikation ist, dass der primäre Anwendungsfall für _Generic für Makros ist, die nicht gut mit C ++ - Namespaces funktionieren. Das acos Beispiel von tgmath ist ein klares Beispiel. C ++ hat die Standardmakros von C bereits verboten und verlangt, dass sie Funktionen sind, aber das funktioniert nicht mit tgmath.h .