Warum ist es nicht möglich, den ternären Operator zu überladen?

Warum kann der ternäre Operator ‘ ?: ‘ nicht überladen werden?

Ich verwende den ternären Operator oft, um if-Anweisungen zu konsolidieren, und bin neugierig, warum die Sprachdesigner entschieden haben, dass dieser Operator nicht überladen wird. Ich habe nach einer Erklärung dafür gesucht, warum in C++-Operatorüberladung, aber keine gefunden, die beschreibt, warum dies nicht möglich ist. Die Fußnote gibt lediglich Auskunft, dass sie nicht überladen werden darf.

Meine erste Vermutung ist, dass das Überladen des Operators fast immer die Nummer eins oder zwei der im obigen Link angegebenen Prinzipien verletzt. Die Bedeutung der Überladung wird selten offensichtlich oder klar sein oder sie weicht von ihrer ursprünglich bekannten Semantik ab.

Meine Frage ist also eher, warum dies nicht möglich ist, als wie, da ich weiß, dass dies nicht möglich ist.

Wenn Sie den ternären Operator überschreiben könnten, müssten Sie Folgendes schreiben:

xxx operator ?: ( bool condition, xxx trueVal, xxx falseVal );

Um Ihre Überschreibung aufzurufen, müsste der Compiler den Wert von beiden berechnen trueVal und falseVal. So funktioniert der eingebaute ternäre Operator nicht – er berechnet nur einen dieser Werte, weshalb Sie Dinge schreiben können wie:

return p == NULL ? 23 : p->value;

ohne sich Gedanken über die Umleitung über einen NULL-Zeiger machen zu müssen.

Ich denke, der Hauptgrund zu dieser Zeit war, dass es sich nicht lohnte, eine neue Syntax nur für diesen Operator zu erfinden. Es gibt kein Token ?:, also müssten Sie dafür eine Reihe spezieller Grammatikregeln erstellen. (Die aktuelle Grammatikregel hat operator gefolgt von einem Operator, bei dem es sich um ein einzelnes Token handelt.)

Da wir (aus Erfahrung) gelernt haben, das Überladen von Operatoren vernünftiger zu verwenden, hat sich herausgestellt, dass wir das Überladen von . wirklich nicht zulassen sollten && und || entweder aus den Gründen, auf die andere Antworten hingewiesen haben, und wahrscheinlich auch nicht mit Operatorkomma (da die überladenen Versionen nicht den Sequenzpunkt haben, den der Benutzer erwartet). Die Motivation, es zu unterstützen, ist also noch geringer als ursprünglich.

Eines der Prinzipien des ternären Operators besteht darin, dass die Wahr/Falsch-Ausdrücke nur basierend auf der Wahrheit oder Falschheit des bedingten Ausdrucks ausgewertet werden.

cond ? expr1 : expr2

In diesem Beispiel expr1 wird nur ausgewertet, wenn cond ist wahr, während expr2 wird nur ausgewertet, wenn cond ist falsch. Wenn wir dies im Hinterkopf behalten, sehen wir uns an, wie eine Signatur für ternäres Überladen aussehen würde (der Einfachheit halber hier feste Typen anstelle einer Vorlage verwenden).

Result operator?(const Result& left, const Result& right) { 
  ...
}

Diese Signatur ist einfach nicht legal, weil sie genau die von mir beschriebene Semantik verletzt. Um diese Methode aufzurufen, müsste die Sprache beides auswerten expr1 und expr2 daher werden sie nicht mehr bedingt ausgewertet. Um ternär zu unterstützen, müsste der Betreiber entweder

1. Nehmen Sie ein Lambda für jeden Wert, damit es sie bei Bedarf erzeugen kann. Dies würde den aufrufenden Code jedoch notwendigerweise komplizieren, da er die Lambda-Aufrufsemantik berücksichtigen müsste, wenn logisch kein Lambda vorhanden war
2. Der ternäre Operator müsste einen Wert zurückgeben, um anzugeben, ob der Compiler verwenden soll expr1 oder expr2

BEARBEITEN

Einige mögen argumentieren, dass das Fehlen von Kurzschlüssen in diesem Szenario in Ordnung ist. Der Grund dafür ist, dass Sie in C++ bereits mit den Kurzschluss bei Operatorüberladungen verletzen können || und &&

Result operator&&(const Result& left, const Result& right) { 
  ...
}

Obwohl ich dieses Verhalten selbst für C++ immer noch verblüffend finde.

Die kurze und genaue Antwort lautet einfach “weil Bjarne sich dafür entschieden hat”.

Obwohl die Argumente darüber, welche Operanden in welcher Reihenfolge ausgewertet werden sollten, eine technisch genaue Beschreibung dessen liefern, was passiert, tragen sie wenig (nicht wirklich) dazu bei, zu erklären, warum dieser spezielle Operator nicht überladen werden kann.

Die gleichen grundlegenden Argumente würden insbesondere auch für andere Operatoren gelten, wie z operator && und operator||. In der integrierten Version jedes dieser Operatoren wird der linke Operand ausgewertet, und zwar genau dann, wenn dies 1 Pro && oder ein 0 Pro ||, wird der rechte Operand ausgewertet. Ebenso wertet der (eingebaute) Kommaoperator seinen linken Operanden aus, dann seinen rechten Operanden.

In einer überladenen Version eines dieser Operatoren beide Operanden werden immer (in nicht spezifizierter Reihenfolge) ausgewertet. Als solche sind sie in dieser Hinsicht im Wesentlichen identisch mit einem überladenen ternären Operator. Sie alle verlieren die gleiche Garantie dafür, welche Operanden in welcher Reihenfolge ausgewertet werden.

Warum Bjarne diese Entscheidung getroffen hat: Ich sehe einige Möglichkeiten. Einer ist, dass der ternäre Operator, obwohl er technisch gesehen ein Operator ist, in erster Linie der Flusskontrolle gewidmet ist if oder while als die meisten anderen Operatoren zu überladen.

Eine andere Möglichkeit wäre, dass es syntaktisch hässlich wäre und den Parser mit etwas wie operator?:, was eine Definition erfordert ?: als Zeichen usw. — alle erfordern ziemlich ernsthafte Änderungen an der C-Grammatik. Zumindest aus meiner Sicht scheint dieses Argument ziemlich schwach zu sein, da C++ bereits ein viel komplexerer Parser als C, und diese Änderung wäre wirklich viel kleiner als viele andere vorgenommene Änderungen.

Das vielleicht stärkste Argument von allen ist einfach, dass es nicht so aussah, als würde es viel bewirken. Da es in erster Linie der Flusskontrolle gewidmet ist, ist es unwahrscheinlich, dass eine Änderung seiner Funktion für einige Arten von Operanden etwas sehr Nützliches bewirkt.

Aus dem gleichen Grund, warum Sie wirklich nicht (obwohl Sie es können) überladen sollten && oder || Operatoren – dies würde Kurzschlüsse bei diesen Operatoren deaktivieren (wobei nur der notwendige Teil und nicht alles bewertet wird), was zu schwerwiegenden Komplikationen führen kann.