Warum müssen statische Elementfunktionen einen impliziten Objektparameter gemäß §13.3.1/4 haben?

Question

In §13.3.1/4 (N3337) finden Sie die folgenden finden:

Für statische Member-Funktionen, ist die implizite Objektparameter betrachtet jedes Objekt übereinstimmen (da, wenn die Funktion aktiviert ist, die Objekt wird verworfen).

§9.4.1/2 hat diese Aussage:

Eine statische Elementfunktion keinen diesen Zeiger.

Was ist der Zweck des impliziten Objektparameters für eine statische Elementfunktion?

Answer 1

Nachstehend folgt eine Beschreibung aus dem Standard, die impliziert, dass implizite Objektparameter zum Überladen verwendet werden.

Bevor die Überladungsauflösung beginnt, werden die durch Namenssuche und Vorlagenargumentabzug ausgewählten Funktionen zur Menge der Kandidatenfunktionen zusammengefasst (die genauen Kriterien hängen vom Kontext ab, in dem die Überladungsauflösung stattfindet). Wenn eine Kandidatenfunktion eine Elementfunktion (statisch oder nicht statisch), aber kein Konstruktor ist, wird sie so behandelt, als hätte sie einen zusätzlichen Parameter (impliziter Objektparameter), der das Objekt darstellt, für das sie aufgerufen werden und erscheint vor dem ersten der aktuellen Parameter.

ähnliche Weise die Aufgabe, die eine Elementfunktion aufgerufen wird, auf die Argumentliste als impliziertes Objekt Argument

für Elementfunktionen der Klasse X vorangestellt wird, die Art des impliziten Objektparameters wird durch cv betroffen -qualifikationen und ref-qualifications der Mitgliedsfunktion.

Für die statischen Elementfunktionen wird der implizite Objektparameter als mit einem beliebigen Objekt übereinstimmend betrachtet: sein Typ wird nicht untersucht, und es wird keine Konvertierungssequenz für ihn versucht.

Answer 2

Es wird verwendet, um die Übersteuerungsauflösung einfacher zu verstehen.

struct S { 
    void f(int); 
    static void f(double); 
}; 

int main() { 
    S::f(1); 
} 

Hier ist s::f(1); einfach ein harter Fehler, weil f(int) eine bessere Übereinstimmung als f(double) ist, obwohl die f(int) Überlastung einen harten Fehler verursacht weiter.

Wenn die Regeln eine andere Art und Weise waren, überlegen, was für das passieren würde:

template <typename T> 
struct U : S { 
    void u() { 
    S::f(1); 
    } 
}; 

template <typename T> 
struct V : U<T> { 
    void v() { 
    S::f(1); 
    } 
}; 

Hier U::u eindeutig gültig ist, und ruft die Member-Funktion. V<T> hat jedoch eine typabhängige Basisklasse, daher ist zum Zeitpunkt der Templatedefinition nicht bekannt, von S abzuleiten. Mit S::f Auflösung zu der f(double) Überlast hier wäre sehr verwirrend.