Kann man auch inline für Konstruktor und Destruktor benutzen?

nman

Oh, im wesentlichen steht da dass Konstruktoren und Destruktoren oft mehr Code enthalten als man annehmen könnte/ selbst überhaupt sieht da es Compilerherstellern freisteht wie genau Klasseninstanzen konstruiert werden, dh. es kann zB vom Compiler generierter Init-Code in den Konstruktor eingefügt werden was Inline-Expansion wesentlich unattraktiver machen würde.

Ein weiterer Punkt der angesprochen wird sind Compile-Time dependencies und die Tatsache dass zB inline-Funktionen in Bibliotheken ebenfalls nicht durch binäre Updates aktualisiert werden können...

rüdiger

ob Funktionen geinlined werden entscheidet der Compiler im Endeffekt selber ob die Funktion geinlined wird.

nman

Habe ich etwas anderes behauptet?

rüdiger

nö, aber unter dem Aspekt ist ja

Oh, im wesentlichen steht da dass Konstruktoren und Destruktoren oft mehr Code enthalten als man annehmen könnte/ selbst überhaupt sieht da es Compilerherstellern freisteht wie genau Klasseninstanzen konstruiert werden, dh. es kann zB vom Compiler generierter Init-Code in den Konstruktor eingefügt werden was Inline-Expansion wesentlich unattraktiver machen würde.

uninteressant. Wenn der dtor unattraktiv für inlining ist, macht der Compiler das eben nicht.

nman

Hm, wie zuverlässig können das Compiler entscheiden wenn der Konstruktor einer Klasse mehrere andere Konstruktoren aufrufen muss?

nman hat es doch schon richtig erläutert. weiß man ob es der compiler inlined, nein. weiß man im ersten augenblick, was der compiler fürn overhead bei konstruktor aufrufen mit initialisiert, nein. deswegen ist es ratsamer bei kostruktor das inline wegzulassen. sicherlich gibt es einen standard, aber weiß man ob sich der compiler dran hält, nein. sicherlich kann man dies mit einen debugger checken, aber dies spielt ja keene rolle..

und ausserdem sollte man darüber keine annahmen mache system internas oder sich auf den compiler verlassen, nach dem motto, ach er wird es schon optimieren.

tobidope

grenouille_unreg schrieb:

nman hat es doch schon richtig erläutert. weiß man ob es der compiler inlined, nein. weiß man im ersten augenblick, was der compiler fürn overhead bei konstruktor aufrufen mit initialisiert, nein. deswegen ist es ratsamer bei kostruktor das inline wegzulassen. sicherlich gibt es einen standard, aber weiß man ob sich der compiler dran hält, nein. sicherlich kann man dies mit einen debugger checken, aber dies spielt ja keene rolle..

und ausserdem sollte man darüber keine annahmen mache system internas oder sich auf den compiler verlassen, nach dem motto, ach er wird es schon optimieren.

Funktionen inlinen sollte man eh erst zum Schluss machen, nachdem man mit einem Profiler über den Code gelaufen ist. Was bringt es 200 get-Funktionen zu inlinen, den Code riesengroß zu machen, aber Performance ganz woanders zu verlieren?

Ich weiß das mein Satzbau und meine Grammatik gestern abend nicht hervorragend war, aber was anderes hab ich auch net geschrieben, oder.

rüdiger

@grenouline_unreg
Beim inlinen geht man ja so vor. Man ruft den Profiler auf, sieht das man hier und da noch ein wenig performance rausholen will, dann inlined man und schaut sich nochmal alles mit dem profiler an. Wenn man nun natürlich eine riesige Binär-Datei hat, dann sollte man sich fragen ob man nicht falsch geinlined hat.

Aber generell sagen, dass man ctor/dtoren nicht inlinen soll, halte ich für genauso falsch, wie andere generelle Regeln zum Thema inline.

Bashar

Geht man so vor? Was ist denn hier dran bitte so falsch:

class Foo {
  int a;
public:
  Foo(int a) : a(a) {}
};

Nicht inlinen tu ich, wenn der ctor zu fett ist, oder aus Abhängigkeitsgründen.

nman

kingruedi schrieb:

Aber generell sagen, dass man ctor/dtoren nicht inlinen soll, halte ich für genauso falsch, wie andere generelle Regeln zum Thema inline.

Hm, die einzige generelle Regel die ich genannt habe war dass man sich das gut überlegen soll und das kann eigentlich nie schaden, hm?

Bashar: Sowas meinte ich doch auch gar nicht, ich hab doch geschrieben dass in EC++ genau die zwei Fälle angesprochen werden die Du genannt hast.