Werden set-/get-Methoden vom Compiler optimiert?

DarthZiu

Der Titel sagt eigentlich schon alles.

Werden set- / get-Methoden beim Kompilieren so optimiert, dass sie die gleiche Ausführungsgeschwindigkeit haben, als wenn ich direkt auf die Variablen zugreifen würde?

Variante 1 (Pseudocode)

class Test {

public:
    Test::Test();
    int wert;
};

int main(void)
{
    for(int i=0; i<100000; i++)
        test.wert++;
}

Variante 2 (Pseudocode)

class Test {

public:
    Test::Test();
    void Test::setWert(int _wert)
    {
        this->wert = _wert;
    }

private:
    int wert;
};

int main(void)
{
    for(int i=0; i<100000; i++)
        test.setWert(i);
}

Welche Variante wäre schneller (oder sind sie gleich schnell)?

/edit:
Vielleicht sollte ich sagen, dass ich unter Windows z.Z. mit VC++ 6.0 entwickle.

HumeSikkins

Welche Variante wäre schneller (oder sind sie gleich schnell)?

Hätte wäre wenn ist bei Performance-Fragen immer uninteressant. Hier hilft nur konkretes Problem messen bzw. konkrete Compiler-Ausgabe prüfen. Man kann zwar sagen, dass solche simplen setter/getter in der Regel von einem Compiler inline expandiert und sind somit am Ende äquivalent zu einem direkten Zugriff sind, aber letztlich ist sowas Problem- und Compiler-abhängig (bzw. Konfigurationsabhängig).

Ich würde mich erstmal Fragen ob und in wie weit die getter/setter aus logischer Sicht sinnvoll sind.

DarthZiu

HumeSikkins schrieb:

Ich würde mich erstmal Fragen ob und in wie weit die getter/setter aus logischer Sicht sinnvoll sind.

Durch diese Frage bin ich ja zu diesem Post gekommen. Ich habe an vielen Stellen meiner Software solche Fälle.

Eigentlich bräuchte ich dort keine set-/get-Methode, aber in gutem Softwaredesign sollte man möglichst alle Member private machen (zumindest an unserer Hochschule) und nur mit settern/gettern zugreifen.

Da ich aber ne zeitkritische Anwendung habe, muss ich einen Kompromiss zwischen "gutem Design" und Geschwindigkeit schaffen.

camper

wenn die anwendung zeitkritisch ist, sollte man allerdings auch wert auf einen compiler legen, der über einen guten optimierer verfügt. fortschritte in C++ compileren beschränken sich schließlich nicht nur auf bessere unterstützung des sprachstandards.

Artchi

Also ein Compiler der das nicht optimiert, würde ich in die Tonne kloppen. Ich empfinde es _heute_ für selbstverständlich das sowas optimiert wird. Compiler-spezifisch hin oder her.

Getter und Setter schreibe ich dann, wenn ich sie brauche. Private Members die von Außen keinen Zugriff brauchen, brauchen auch keine public-Methoden. Wenn getter/setter nötig sind, schreib ich sie hin.

HumeSikkins

DarthZiu schrieb:

HumeSikkins schrieb:

Ich würde mich erstmal Fragen ob und in wie weit die getter/setter aus logischer Sicht sinnvoll sind.

Durch diese Frage bin ich ja zu diesem Post gekommen. Ich habe an vielen Stellen meiner Software solche Fälle.

Eigentlich bräuchte ich dort keine set-/get-Methode, aber in gutem Softwaredesign sollte man möglichst alle Member private machen (zumindest an unserer Hochschule) und nur mit settern/gettern zugreifen.

Das ist eine blödsinnige Denkmethode. Ein Design wird nicht dadurch besser, dass man ein Attribut hinter einem set-/get-Paar versteckt (und die dann am Besten noch inline im Header implementiert). Ein gutes Design abstrahiert von den konkreten Daten und bietet stattdessen sinnvolle Dienste (Funktionen). Auf logischer Ebene sollte man Paare von set-/get-Methoden erstmal genauso kritisch betrachten, wie öffentliche Member.

Da ich aber ne zeitkritische Anwendung habe, muss ich einen Kompromiss zwischen "gutem Design" und Geschwindigkeit schaffen.

Eine zeitkritische Anwendung ist niemals überall zeitkritisch, deshalb ist es so wichtig, dass du konkrete Messungen machst. Alles andere führt dazu, dass man Kompromisse macht, die weder nötig noch sinnvoll sind.