Wie finde ich heraus ob eine Methode ein Kandidat für inline ist?
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
HumeSikkins schrieb:
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.
Ich stimme dir hundertprozentig zu. Wenn ich sage inline, dann ist nicht unbedingt inline expansion gemeint. Diese Formulierung ist nicht eindeutig.
Warum aber kannst du nicht einfach einsehen, dass inline expansion das Thema DIESES Threads war? Warum musst du dich jetzt in so Kleinigkeiten mit dem C++ Standard verkünsteln, wenn du genau weißt, um was es geht?
Geht es jetzt darum, mit irgendwelchen Spitzfindigkeiten recht zu haben, oder die Frage zu beantworten, für welche Funktionen sich inlining lohnt?
-
er will uns verwirren.
find ich nicht gut.
-
Wenn du inline hörst denkst du al erstes an die expansion. Wenn Hume inline hört denkt er aber an das, was man unter inline versteht. Darin besteht das Problem.
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??
Du könntest bei der Konstruktion den Namen definieren!?! Ob das bei einem Button immer sinnvoll ist sei dahingestellt. Aber es gibt viele Dinge mit eigenschaften, dei im Grunde bei ihrer Erstellung definiert werden und später nicht mehr veränderbar sind. Nehmen wir ein Mensch. Er hat ein Geburtsdatum. Dennoch wäre ein set_geburtsdatum totaler Schwachsinn. Das Datum sollte unbedint bei der Konstruktion einmalig festgelegt werden.
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.
ERstens welche Attribute haben Klassen denn so? Meinst du vielleicht Objekte? Wir reden doch immernoch über die Objektorientierung und nicht über ein willkürlich von dir erfundenes Paradigma à la Klassenorientierung. Und Variablen sind doch nur eine Art Objekte darzustellen.
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.
Hä? Entweder es macht designtechnisch Sinn ein Attribut öffentlich zugänglich zu machen oder nicht. Meistens macht es das nicht. Fertig. Das falls es nötig und sinnvoll ist, Setter und Getter zu verwenden, damit es nicht zur Inkonsitenz kommt und um sich vor übermäßigen Veränderungen des Programms zu schützen, falls die interne Darstellung verändert wird, steht wohl außer Frage.
-
Helium schrieb:
Du könntest bei der Konstruktion den Namen definieren!?! Ob das bei einem Button immer sinnvoll ist sei dahingestellt. Aber es gibt viele Dinge mit eigenschaften, dei im Grunde bei ihrer Erstellung definiert werden und später nicht mehr veränderbar sind. Nehmen wir ein Mensch. Er hat ein Geburtsdatum. Dennoch wäre ein set_geburtsdatum totaler Schwachsinn. Das Datum sollte unbedint bei der Konstruktion einmalig festgelegt werden.
Ja klar, bei einem Button kann das sein. Deshalb hab ich ja auch gesagt ein Label oder besser noch TextEdit wäre hier vielleicht ein treffenderes Beispiel.
Und das mit dem Geburtstag - ich hab explizit gesagt setter nur gegebenenfalls.
Aber selbst da ließe sich streiten ob man dem Nutzer die Möglichkeit einräumen sollte Fehleingaben zu korrigieren.Helium schrieb:
ERstens welche Attribute haben Klassen denn so? Meinst du vielleicht Objekte? Wir reden doch immernoch über die Objektorientierung und nicht über ein willkürlich von dir erfundenes Paradigma à la Klassenorientierung. Und Variablen sind doch nur eine Art Objekte darzustellen.
Welche Attribute Klassen so haben? Ganz einfach Eigenschaften die ein bestimmtes Objekt welches durch die Klasse modelliert wird hat und die relevant sind. Und das unterscheidet, zumindest in meinen Augen, diese Variablen von denen welche einfach nur Berechnungsergebnisse cachen oder organisatorischer Natur sind.
Und ich weiß gar nicht was das mit den Paradigmen soll. Reden wir hier über Design oder nicht?