Nicht statisches Mitglied als Standardargument einer nicht statischen Mitgliedsfunktion [duplicate]

struct X
{
   X():mem(42){}
   void f(int param = mem) //ERROR
   {
      //do something
   }
private: 
   int mem;
};

Kann mir jemand nur einen Grund nennen, warum dies in C++ illegal ist?! Das heißt, ich weiß, dass es sich um einen Fehler handelt, ich weiß, was der Fehler bedeutet, ich kann einfach nicht verstehen, warum das illegal sein sollte!

Ihr Code (vereinfacht):

struct X
{
   int mem;
   void f(int param = mem); //ERROR
};

Sie möchten nicht statische Elementdaten als Standardwert für einen Parameter einer Elementfunktion verwenden. Die erste Frage, die mir in den Sinn kommt, ist diese: Welche bestimmte Instanz der Klasse den Standardwert mem gehört?

X x1 = {100};  //mem = 100
X x2 = {200};  //mem = 200

x1.f(); //param is 100 or 200? or something else?

Ihre Antwort könnte sein 100 wie f() wird für das Objekt aufgerufen x1 was hat mem = 100. Wenn dies der Fall ist, muss die Implementierung implementiert werden f() wie:

void f(X* this, int param = this->mem);

was wiederum erfordert, dass das erste Argument zuerst initialisiert wird, bevor das andere Argument initialisiert wird. Der C++-Standard legt jedoch keine Initialisierungsreihenfolge der Funktionsargumente fest. Daher ist das nicht erlaubt. Aus dem gleichen Grund, aus dem C ++ Standard nicht einmal dies zulässt:

int f(int a, int b = a); //§8.3.6/9

Tatsächlich heißt es in §8.3.6/9 ausdrücklich:

Standardargumente werden bei jedem Aufruf der Funktion ausgewertet. Die Reihenfolge der Auswertung von Funktionsargumenten ist nicht festgelegt. Folglich dürfen Parameter einer Funktion nicht in Standardargumentausdrücken verwendet werdenauch wenn sie nicht ausgewertet werden.

Und der Rest des Abschnitts ist eine interessante Lektüre.

Ein interessantes Thema im Zusammenhang mit “Standard” -Argumenten (jedoch nicht mit diesem Thema verwandt):

• Standardargument in der Mitte der Parameterliste?

Standardargumente müssen zur Kompilierzeit bekannt sein. Wenn Sie über so etwas wie einen Funktionsaufruf sprechen, dann ist die Funktion zur Kompilierzeit bekannt, auch wenn der Rückgabewert nicht bekannt ist, sodass der Compiler diesen Code generieren kann, aber wenn Sie standardmäßig eine Member-Variable verwenden, tut der Compiler dies nicht nicht wissen, wo diese Instanz zur Kompilierzeit zu finden ist, was bedeutet, dass sie effektiv einen Parameter übergeben müsste (this) um mich zu finden. Beachten Sie, dass Sie so etwas nicht tun können void func(int i, int f = g(i)); und die beiden sind effektiv die gleiche Einschränkung.

Ich finde diese Einschränkung auch doof. Aber C++ ist voller alberner Beschränkungen.

Wie DeadMG oben erwähnt hat, so etwas wie

void func(int i, int f = g(i))

ist aus dem gleichen Grund illegal. Ich vermute jedoch, dass es sich nicht einfach um eine dumme Einschränkung handelt. Um eine solche Konstruktion zu ermöglichen, müssen wir die Auswertungsreihenfolge für Funktionsparameter einschränken (da wir dies vor this->mem berechnen müssen), aber der C++-Standard lehnt explizit alle Annahmen zur Auswertungsreihenfolge ab.

Die akzeptierte Antwort in der doppelten Frage lautet warum, aber der Standard gibt auch ausdrücklich an, warum dies so ist:

8.3.6/9:

”
Beispiel: Die Deklaration von X::mem1() im folgenden Beispiel ist falsch formatiert, da für das als Initialisierer verwendete nichtstatische Element X::a kein Objekt bereitgestellt wird.

int b;
class X
  int a;
  int mem1(int i = a);    // error: nonstatic member a
                          // used as default argument
  int mem2(int i = b);    // OK: use X::b
  static int b;
};

Die Deklaration von X::mem2() ist jedoch sinnvoll, da kein Objekt benötigt wird, um auf das statische Element X::b zuzugreifen. Klassen, Objekte und Mitglieder werden in Abschnitt 9 beschrieben. “

… und da es keine Syntax gibt, um das Objekt bereitzustellen, das zum Auflösen des Werts von erforderlich ist X::a An diesem Punkt ist es praktisch unmöglich, nichtstatische Elementvariablen als Initialisierer für Standardargumente zu verwenden.

ISO C++ Abschnitt 8.3.6/9

ein nicht statisches Element darf nicht in einem Standardargumentausdruck verwendet werdenauch wenn es nicht ausgewertet wird, es sei denn, es erscheint als id-Ausdruck eines Klassenmitglieds-Zugriffsausdrucks (5.2.5) oder es wird verwendet, um einen Zeiger auf ein Mitglied zu bilden (5.3.1).

Sehen Sie sich auch das Beispiel in diesem Abschnitt an.

Aus einem Grund, weil f ist öffentlich, aber mem ist privat. Als solches codieren Sie wie folgt:

int main() { 
    X x;
    x.f();
    return 0;
}

… würde externen Code beinhalten, der die privaten Daten von X abruft.

Abgesehen davon würde (oder könnte) es auch die Codegenerierung etwas knifflig machen. Wenn der Compiler ein Standardargument verwendet, erhält er normalerweise den Wert, den er als Teil der Funktionsdeklaration übergeben wird. Das Generieren von Code zum Übergeben dieses Werts als Parameter ist trivial. Wenn Sie möglicherweise ein Element eines Objekts übergeben (möglicherweise willkürlich tief verschachtelt) und dann Dinge wie die Möglichkeit hinzufügen, dass es sich um einen abhängigen Namen in einer Vorlage handelt, kann dies (zum Beispiel) ein anderes Objekt mit einer Konvertierung in das richtige Ziel benennen type, und Sie haben ein Rezept, um die Codegenerierung ziemlich schwierig zu machen. Ich weiß es nicht genau, aber ich vermute, dass jemand über solche Dinge nachgedacht und entschieden hat, dass es besser ist, konservativ zu bleiben, und möglicherweise später ausdünnt, wenn ein triftiger Grund dafür gefunden wurde. Angesichts der vielen Male, die ich gesehen habe, dass daraus Probleme entstehen, würde ich vermuten, dass es lange so bleiben wird, wie es ist, einfach weil es selten Probleme verursacht.

Der Compiler muss Adressen kennen, um die Standardwerte zur Kompilierzeit beizubehalten. Adressen von nicht statischen Mitgliedsvariablen sind zur Kompilierzeit unbekannt.