Eigene Vektorenklasse (Fragen, Verbesserungen)

[hustbaer]

@unkwnusr sagte in Eigene Vektorenklasse (Fragen, Verbesserungen):

@hustbaer @SeppJ
Also könnte ich doch quasi, wenn ich eine Klasse "Person" habe
die Methoden wie beispielsweise getName() auch inline machen oder nicht?
Diese Methode ist ja kurz und knackig.

Da kann man sich schnell täuschen. Der C++ Code ist zwar bloss return m_Name;, aber der Asselblercode der da draus wird ist gar nicht "knackig": https://godbolt.org/z/1eae88nxK

Also ja, kannst du. Bringt aber eher nix.

[Finnegan]

@SeppJ sagte in Eigene Vektorenklasse (Fragen, Verbesserungen):

Das ist korrekt, dass dies die Absicht hinter der Existenz des Schlüsselwortes ist. Praktisch entscheidet das der Compiler aber selber schon ganz gut, und trifft seine eigene Entscheidungen, ganz unabhängig von dem inline Schlüsselwort.

Ich denke es macht Sinn, beim inline-Schlüsselwort höchstens noch aus historischen Gründen dessen ursprüngliche Motivation zu erwähnen

Dessen de facto einzige effektive Bedeutung ist heutzutage dein "anderer Nebeneffekt": "mehrere Definitionen sind erlaubt", was inline nicht zu einem Optimierungs- sondern zu einem Code- und Projektstruktur-Werkzeug macht. Gerade auch die etwas neueren inline-Variablen haben eigentlich gar nichts mehr mit dem ursprünglichen inlining zu tun. Das ist meines erachtens alles, was man als Anfänger zu wissen braucht. Auch die Größe der Funktion ist bei inline irrelevant. Die einzige Frage ist, ob der Aufbau des Projekts an dieser Stelle inline erfordert, z.B. weil selbst die 200-Zeilen-Funktion aus welchem Grunde auch immer im Header definiert sein soll (Header-Only Library z.B.).

Will man Compiler-Inlining steuern, sollte man compiler-spezifische Werkzeuge wie __attribute__((always_inline)) oder __attribute__((noinline)) oder auf Build-Ebene LTO und spezielle Optimierungs-Flags verwenden. Bei Ersteren sollte man dann allerdings wirklich wissen was und warum man es tut. Hier wird die "Größe" der Inline-Funktion tatsächlich relevant.

[wob]

@Finnegan Ich stimme dir generell diesbezüglich zu, aber ich habe auch mal in die CppCoreGuidelines geschaut und finde dort https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f5-if-a-function-is-very-small-and-time-critical-declare-it-inline:

Over the last 40 years or so, we have been promised compilers that can inline better than humans without hints from humans. We are still waiting. Specifying inline (...) encourages the compiler to do a better job.

[Th69]

@hustbaer sagte in Eigene Vektorenklasse (Fragen, Verbesserungen):

Da kann man sich schnell täuschen. Der C++ Code ist zwar bloss return m_Name;, aber der Asselblercode der da draus wird ist gar nicht "knackig": https://godbolt.org/z/1eae88nxK

Also ja, kannst du. Bringt aber eher nix.

Da wird ja auch ein String-Kopie erzeugt, also

std::string Name(){
  return std::string(m_Name);
}

Bei

const std::string& Name() const {
  return m_Name;
}

sind es nur noch zwei Assembler-Mnemonics: geänderter Code

Oder ohne Optimierung kompilieren.

[Finnegan]

@wob sagte in Eigene Vektorenklasse (Fragen, Verbesserungen):

@Finnegan Ich stimme dir generell diesbezüglich zu, aber ich habe auch mal in die CppCoreGuidelines geschaut und finde dort https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f5-if-a-function-is-very-small-and-time-critical-declare-it-inline:

Over the last 40 years or so, we have been promised compilers that can inline better than humans without hints from humans. We are still waiting. Specifying inline (...) encourages the compiler to do a better job.

Ja, ich muss zugeben, dass ich tatsächlich den Code der Compiler nicht im Detail kenne und weiss, ob die inline tatsächlich auch als "Hint" interpretieren. Wenn mir inlining oder nicht wichtig ist, verwende ich die compiler-spezifischen Attribute.

In dem Sinne halte ich es aber für nicht gut, wenn inline zwei Bedeutungen hat. Vielleicht will man ja eine inline-Funktion, weil sie im Header ein soll, aber man möchte nicht, dass sie geinlined wird. Ich meine mich sogar vage erinnern zu können, schonmal irgendwo eine inline __attribute__((noinline)) f()-Funktion geschrieben zu haben

[unkwnusr]

@Th69
Aus welchen Gründen sollte ich denn eine Methode beispielsweise so implementieren

const std::string& getName() const{}

Hier geht es sich darum, dass eine String-Referenz zurückgegeben wird.
Liegt das daran, dass "std::string" benutzt wird? Oder gibt es da eine Regel so wie "pi*Daumen"

[SeppJ]

Wenn du mit Implementierung wirklich meinst, dass diese leer sein sollte (weil du {} am Ende schreibst): Nie.

Wenn du meinst, warum man eine const-Referenz zurückgeben sollte: Es ist effizient. Faustregel: Alles was groß (viele Mal die Größe eines Pointers) oder dynamisch (wie hier der String) ist, ist teuer zu kopieren. Falls der Aufrufer unbedingt eine Kopie will, kann er sie immer noch selber machen.

[unkwnusr]

@SeppJ
Nein, die Funktion ist einfach leer für das Beispiel jetzt.
Alles klar, das hilft mir weiter, danke.

[Th69]

Und umgekehrt solltest du bei deinen Getter-Funktionen auch direkt float zurückgeben.
Und den Rückgabetyp bei isZero solltest du auch noch mal anpassen.

[*john 0]

@SeppJ sagte in Eigene Vektorenklasse (Fragen, Verbesserungen):

Wenn du meinst, warum man eine const-Referenz zurückgeben sollte: Es ist effizient. Faustregel: Alles was groß (viele Mal die Größe eines Pointers) oder dynamisch (wie hier der String) ist, ist teuer zu kopieren. Falls der Aufrufer unbedingt eine Kopie will, kann er sie immer noch selber machen.

Teuer ist alles zu kopieren, was größer als eine Cache Line ist. Darunter wird bei korrekter Ausrichtung die Cache Line so oder so gelesen.

Das erinnert mich an folgenden Vortrag von der CppCon 2016.

[unkwnusr]

@Th69
Was genau ist bei dem Rückgabetypen von isZero denn falsch?

[*john 0]

@unkwnusr sagte in Eigene Vektorenklasse (Fragen, Verbesserungen):

@Th69
Was genau ist bei dem Rückgabetypen von isZero denn falsch?

Du gibst eine Referenz auf float zurück, isZero sollte eigentlich bool zurückliefern.

[unkwnusr]

@john-0
Stimmt. Habe ich nicht drüber nachgedacht.