Wie finde ich heraus ob eine Methode ein Kandidat für inline ist?

HumeSikkins

Hallo,
1. inline war schon *immer* nur eine Bitte an den Compiler. Das hat mit neueren oder älteren nichts zu tun. Jeder Compiler darf inline Funktionen outline generieren. Oder auch outline Funktionen inline.

2. inline-Funktionen sollen *gerade nicht* wie Makros funktionieren. Inline-Funktionen sollen im sichtbaren Verhalten nicht von Funktionen zu unterscheiden sein.

3. Sowohl die Größe als auch die Komplexität einer Funktion spielen bei inline eine Rolle. Große/komplexe Funktionen eignen sich nicht für das inlinen, da ihre Abarbeitung den Aufwand des Aufrufs dominiert. Man erkauft sich also die Nachteile von inline ohne etwas gutes dafür zu bekommen.

4. inline kann auf Memberfunktionen ganz genauso angewendet werden wie auf normale Funktionen. Die Referenzierung einer Membervariablen ist für die Inline-Betrachtung unerheblich. Problematisch sind z.B. virtuelle Funktionen. Die können nur geinlined werden, wenn der Compiler garantieren kann, dass statischer Typ beim Aufruf immer gleich dem dynamischen Typ ist.

5. Funktionen/Methoden die Schleifen oder Rekursion enthalten werden in der Regel niemals geinlined.

6. getter und setter sind nicht grundsätzlich gute Kandidaten für inline. getter und setter sind erstmal grundsätzlich schlecht (aus Sicht der OOP). Davon ab: Jede inline-Funktion führt zu höheren Abhängigkeiten, da Clientcode von der *Implementation* (nicht nur vom Interface) jeder Inline-Funktion abhängig ist. Eine inline-Funktion kann nicht verändert werden, ohne das *alle* Clients neukompiliert werden müssen. Sowas sollte man nicht ohne gute Gründe in Kauf nehmen.

7. Der beste Grund eine Methode/Funktion inline zu machen ist der, dass *Messungen* mit einem Profiler ergeben haben, dass dies einen Laufzeit- oder Speichervorteil bringt. Alles andere ist "premature optimization".

HumeSikkins

Jover schrieb:

Shade Of Mine schrieb:

inline verwendet man nur noch um die ODR auszutricksen

Was bitte sind ODR?

ODR = One definition rule

Maxi

wie würde eine rekursive Funktion inline aussehen?
Das geht gar nciht
is ja logisch...

Ich benutze inline immer dann, wenn man kleine Funkitonen hat, die nur einen Wert setzen, oder zum BEispiel gerade eben geproggt

BOOL meKeyDown(DWORD Key) { return g_KeyState[Key] & 0x80; };

sowas nehme ich als inliine

Shade Of Mine

Maxi schrieb:

wie würde eine rekursive Funktion inline aussehen?
Das geht gar nciht
is ja logisch...

Warum?
was ist rekursion anderes als eine schleife?
und was kann man mit schleifen machen?
'unrollen'
natürlich nicht immer, aber manchmal geht es. bzw. geht es ja mit einer transformation in eine schleife, wobei der körper geinled werden kann.

Möglich ist es, aber meistens nicht zweckmäßig

Ich benutze inline immer dann, wenn man kleine Funkitonen hat, die nur einen Wert setzen, oder zum BEispiel gerade eben geproggt
BOOL meKeyDown(DWORD Key) { return g_KeyState[Key] & 0x80; };
sowas nehme ich als inliine

und wenn du lesen würdest was Hume und ich so schreiben, dann würdest du inline nur noch verwenden um an der ODR vorbei zu kommen.

denn was kann der compiler besser als du?
richtig: inlinen

Walli

HumeSikkins schrieb:

6. getter und setter sind nicht grundsätzlich gute Kandidaten für inline. getter und setter sind erstmal grundsätzlich schlecht (aus Sicht der OOP).

Und das von dir? Kannst du das bitte erläutern? Oder meintest du das im Sinne von: "getter und setter sind grundsätzlich schlechte Kandidaten für inline".

HumeSikkins

"getter und setter sind grundsätzlich schlechte Kandidaten für inline".

Nein. Ich meine das im Sinne von "getter und setter sind aus OOP-Sicht schlecht".

Öffentliche Member sind schlecht, da sind wir uns wohl alle einige. getter und setter, letztlich elaborierte öffentliche Variablen, haben aber ähnliche Probleme. Sie untergraben die Kapselung, also das Schützen und Verbergen von Implementationsdetails. getter und setter weichen die Kapsel auf, sie verraten viel zu viel über das Innenleben eines Objekts.

Ein schöner Artikel: Why getter and setter methods are evil.

denn was kann der compiler besser als du?
richtig: inlinen

Das würde ich so nicht unterschreiben. Der Compiler kann vielleicht besser inlinen als ich gute inline-Stellen *raten* kann. Mit einem funktionierendem Programm und einem Profiler an der Hand kann man aber durchaus noch gute Ergebnisse erziehlen.

Walli

HumeSikkins schrieb:

Öffentliche Member sind schlecht, da sind wir uns wohl alle einige. getter und setter, letztlich elaborierte öffentliche Variablen, haben aber ähnliche Probleme. Sie untergraben die Kapselung, also das Schützen und Verbergen von Implementationsdetails. getter und setter weichen die Kapsel auf, sie verraten viel zu viel über das Innenleben eines Objekts.

Ok, dem stimme ich zu. Ich verstecke auch immer möglichst viel meiner Implementationsdetails, aber in manchen Situationen braucht man getter/setter einfach. Gut, man muss sie nicht unbedingt getFoo und setFoo nennen . Es gibt durchaus kreativere Namen die die Details nicht offenlegen...

http://www.informatik.fh-muenchen.de/~schieder/programmieren-1-ws96-97/inlining.html

Das mit dem in-der-Klasse-definierte-Methoden-sind-automatisch-inline wird aber wahrscheinlich heute nicht mehr so ganz stimmen.

Shade Of Mine

HumeSikkins schrieb:

denn was kann der compiler besser als du?
richtig: inlinen

Das würde ich so nicht unterschreiben. Der Compiler kann vielleicht besser inlinen als ich gute inline-Stellen *raten* kann. Mit einem funktionierendem Programm und einem Profiler an der Hand kann man aber durchaus noch gute Ergebnisse erziehlen.

Natuerlich. Pauschalisieren kann man diese Aussage nicht.
Generell lass ich den Compiler diese Kleinigkeiten optimieren, denn um ehrlich zu sein, bisher hat es immer gereicht den Algorithmus zu verbessern oder bessere Datenstrukturen zu waehlen, oder einfach das Design leicht zu aendern um die benoetigte Performance zu bekommen.

Mr. N

HumeSikkins schrieb:

denn was kann der compiler besser als du?
richtig: inlinen

Das würde ich so nicht unterschreiben. Der Compiler kann vielleicht besser inlinen als ich gute inline-Stellen *raten* kann. Mit einem funktionierendem Programm und einem Profiler an der Hand kann man aber durchaus noch gute Ergebnisse erziehlen.

Dumm nur, dass die meisten Compiler inline ignorieren.

HumeSikkins

Optimizer schrieb:

http://www.informatik.fh-muenchen.de/~schieder/programmieren-1-ws96-97/inlining.html

Das mit dem in-der-Klasse-definierte-Methoden-sind-automatisch-inline wird aber wahrscheinlich heute nicht mehr so ganz stimmen.

Das war so, ist so und wird wohl auch immer so sein.

Ich glaube nicht, dass wenn ich eine fette Methode mit 500 Anweisungen schreibe und die in meinem Programm noch an 20 Stellen aufrufe, dass die geinlined wird.
Und wenn im Standard was anderes steht, halten sich trotzdem nicht alle Compiler dran.

Bashar

Optimizer: Wenn im Standard von inline die Rede ist, dann ist damit gemeint, dass die Funktion in jeder Übersetzungseinheit, in der sie benutzt wird, definiert werden muss (sprich im Header und nicht in einer separaten Implementierungsdatei).
Der Standard sagt explizit nichts über die Codeerzeugung an sich, nur über das Verhalten des Programms. Da du mit einem konformen Programm nicht herausfinden kannst, ob eine Funktion inline expandiert wurde, ist die Entscheidung darüber grundsätzlich dem Compiler (bzw. demjenigen, der den Compiler designt hat) überlassen ("as-if-Regel").

Ok, das ist mir schon klar. Wir haben jetzt aber meiner Meinung nach eindeutig von der Codeerzeugung geredet und nicht von Übersetzungseinheiten.
Es ging schließlich darum, rauszufinden, ob es sich für eine Funktion lohnt, sie als inline zu deklarieren.

HumeSikkins

Wir haben jetzt aber meiner Meinung nach eindeutig von der Codeerzeugung geredet und nicht von Übersetzungseinheiten.

Wir sprachen und sprechen von inline. Und zwar im Kontext von *Standard*-C++, denn dies ist das Standard-C++ Forum. Nicht das humpty-dumpty Forum.

Du schreibst:

Das mit dem in-der-Klasse-definierte-Methoden-sind-automatisch-inline wird aber wahrscheinlich heute nicht mehr so ganz stimmen

Und das ist schlicht und einfach falsch.

Deine Reaktion auf meine Antwort:

Ich glaube nicht, dass wenn ich eine fette Methode mit 500 Anweisungen schreibe und die in meinem Programm noch an 20 Stellen aufrufe, dass die geinlined wird.

Das ist wiederum eine sinnlose Antwort. Denn erstens geht es hier nicht um glauben und zweitens hat inline eine fest definierte Bedeutung. Und die ist eben gerade *nicht*, dass eine so deklarierte Funktion tatsächlich immer inline generiert wird. Es spielt *keine* Rolle wie lang deine Methode ist. Wenn du sie *innerhalb* der Klassendefinition definiertst ist sie inline. Punkt. Kein Glaube, keine Diskussion einfach Fakt.

Vielleicht meintest du bereits in deiner ersten Aussage sowas wie: "Eine 500
Zeilen Methode wird wohl kaum inline expandiert werden".
Vielleicht ging es dir schon da lediglich um die Möglichkeit zur inline-Expansion.
In diesem Fall liegst du mit deiner Aussage sicher richtig, nur hast du das nicht gesagt. Und ich für meinen Teil verlasse mich mehr auf das was du sagst, statt mir zu überlegen was du dir eigentlich gedacht hast.

Es ging schließlich darum, rauszufinden, ob es sich für eine Funktion lohnt, sie als inline zu deklarieren

Das ist richtig. Nur hast *du* einen anderen Punkt auf's Tablett gebracht.

Der Punkt ist ganz einfach: Wenn du über inline redest, dann musst du dir im klaren sein was du meinst. Und du musst es auch deutlich machen.
Alles andere ist Uga Buga im trüben Teich.

DrGreenthumb

HumeSikkins schrieb:

Wir haben jetzt aber meiner Meinung nach eindeutig von der Codeerzeugung geredet und nicht von Übersetzungseinheiten.

Wir sprachen und sprechen von inline. Und zwar im Kontext von *Standard*-C++, denn dies ist das Standard-C++ Forum. Nicht das humpty-dumpty Forum.

Naja, es ging doch eindeutig von Anfang an um "inline" als "Inline-Expansion" und nicht um irgendwelche Inline-Definitionen aus dem C++ Standard.

HumeSikkins

DrGreenthumb schrieb:

HumeSikkins schrieb:

Wir haben jetzt aber meiner Meinung nach eindeutig von der Codeerzeugung geredet und nicht von Übersetzungseinheiten.

Wir sprachen und sprechen von inline. Und zwar im Kontext von *Standard*-C++, denn dies ist das Standard-C++ Forum. Nicht das humpty-dumpty Forum.

Naja, es ging doch eindeutig von Anfang an um "inline" als "Inline-Expansion" und nicht um irgendwelche Inline-Definitionen aus dem C++ Standard.

Es ist zwar schon lange her, dass ich lesen gelernt habe, aber für mich steht hier:

Das mit dem in-der-Klasse-definierte-Methoden-sind-automatisch-inline wird aber wahrscheinlich heute nicht mehr so ganz stimmen.

NICHT EIN WORT von Expandierung. Das steht *sind-automatisch-inline*. Nicht *werden-automatisch-inline-expandiert*. NOCH NIE bedeutete inline = garantiert inline expandiert. NOCH NIE bedeutete in-der-Klasse-definiert = garantiert inline expandiert.
Trotzdem *IST* eine solche Methode inline. Sie WAR es, sie IST es und sie wird es wahrscheinlich immer SEIN.

Ich verstehe nicht, warum ihr mir hier jetzt eine Klinke bezüglich des Topic-Themas ans Bein diskutieren wollt. Ein einfaches "Ok. Wusste ich nicht" oder "Ok. Habe ich mich schlecht ausgedrückt. Ich meinte Foo" wäre viel sinnvoller und ehrlicher.

finix

HumeSikkins schrieb:

Nein. Ich meine das im Sinne von "getter und setter sind aus OOP-Sicht schlecht".

Das kann ich nicht wirklich nachvollziehen.
Wenn eine Klasse ein bestimmtes Attribut (im Design-technischem Sinne, also nicht gleichzusetzen mit Variable) hat dann muss man doch dieses Attribut abfragen können. Und wenn die Objekte nicht Immutable sein sollen wird es auch das ein oder andere Attribut geben welches man setzten können muss, oder?

Shade Of Mine

Natürlich gibt es Situationen wo man getter und setter braucht.

zB ist es bei einem GUI Button recht nett, wenn man per setText und getText die beschriftung lesen und schreiben kann.

Aber Hume meint, dass viele getter und setter sinnlos sind. Denn oft verwenden Leute getter und setter für alle Variablen, und machen somit nicht viel anderes als public Variablen zu deklarieren.

Denn getter und setter sind generell schlecht, allerdings gibt es auch Situationen wo man sie braucht.

finix

Shade Of Mine schrieb:

Aber deshalb hab ich ja von Attributen gesprochen
zB ist es bei einem GUI Button recht nett, wenn man per setText und getText die beschriftung lesen und schreiben kann.

recht nett? Recht nett ist gut. Wie würde denn ein Button oder noch besser Label aussehen ohne get- und setText??

Shade Of Mine schrieb:

Aber Hume meint, dass viele getter und setter sinnlos sind.

Ja, sicher, die in dem Artikel Beschriebenen "structs in C++" sind mies. Und hin und wieder macht es auch Sinn statt z.B. ein int zurückzugeben ein result_type zu typedefen, oder statt einer const Referenz sich zu überlegen eine bestimmte Eigenschaft als Objekt zurückzugeben für den Fall dass sich was ändern sollte.
Aber trotzdem --

Shade Of Mine schrieb:

Denn oft verwenden Leute getter und setter für alle Variablen, und machen somit nicht viel anderes als public Variablen zu deklarieren.
Denn getter und setter sind generell schlecht, allerdings gibt es auch Situationen wo man sie braucht.

Dem kann ich nicht zu stimmen (außer dem mit den Leuten vielleicht ). Klassen haben nun mal bestimmte Attribute (wieder im Unterschied zu Variablen allgemein) die abgefragt werden und ggf. unter kontrollierten Bedingungen gesetzt werden müssen. Und in diesem Sinn sehe ich sie auch ganz einfach als public Attribute.
Nur weil manche Leute fröhlich interne Daten exportieren und die Methoden dazu entsprechen prefixen heisst das ja noch Lange nicht das getter und setter schlecht sind - im Gegenteil, getter und setter im eigentlichen Sinn schützen öffentlich zugängliche Attribute vor illegalen/inconsistenten/usw Modifikationen.