Eigene Vektorenklasse (Fragen, Verbesserungen)



  • Mir ist gerade noch aufgefallen, wenn ich im header folgendes deklariere

    inline const float getX() const;
    

    und im source dann folgendes definiere

    const float Vector3D::getX() const{
    return m_Array[0];
    }
    

    und in der Main wie folgt benutzen möchte

    Vector3D vec3 = {42, 32, 22};
    std::cout << vec3.getX();
    

    bekomme ich ein unresolved external symbol .... "referenced in function main"

    Heißt das, dass ich inline functions direkt in der Header-File definieren sollte?


  • Mod

    Wie schon gesagt, Funktionen in der Klassendefinition sind sowieso inline:

    class Person{
    public:
     Person() = default;
     Person(std::string& name) : m_Name(name){}
    
      std::string Name(){
    return m_Name;
    }
    
    private:
    std::string m_Name;
    }
    

    Name() ist hier schon inline.

    inline ohne Code macht keinen Sinn. Das inline ist eine Eigenschaft des Codeblocks, es ist kein Teil der Signatur einer Klasse. Wenn du eine Funktion nur deklarieren möchtest, dann macht es überhaupt keinen Unterschied, ob sie später inline definiert ist oder nicht.

    void foo();
    
    // […]
    
    inline void foo()
    {
      // Code
    }
    

    Wieso man das bei einer Inlinefunktion je machen sollte, ist eine gute Frage. Vielleicht wenn man am Anfang eines Headers eine Übersichtssektion über alle Funktionen haben möchte, ohne Implementierungen dazwischen?



  • @SeppJ

    Ja genau. Es ist ja schöner, wenn man dort nur die Deklarationen hat und keine Implementierungen.
    Habs aber jetzt verstanden und schon umgeändert und meine Frage wurden super beantwortet.
    Vielen Dank!



  • @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.



  • @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.



  • @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.

    🙂



  • @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.



  • @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 😉



  • @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" 😃


  • Mod

    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.



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



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



  • @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.



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



  • @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.



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


Anmelden zum Antworten