Eigene Vektorenklasse (Fragen, Verbesserungen)

[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.