Schablonen/Templates



  • Hallo, Ich habe mal eine Frage zu folgenden 2 Beispielen:

    1. Beispiel:
    IntList(const IntList& list); //Konstruktor der Klasse IntList
    void append(const int& x);
    void prepend(const int& x);

    wird zu ==>

    List(const List<T>& list);
    void append(const T& x);
    void prepend(const T& x);

    also int -> T

    2. Beispiel

    bool Contains(int aElem);
    void Delete(int aElem);
    void Insert(int aElem);

    wird zu ==>

    bool Contains(T& aElem);
    void Delete(T& aElem);
    void Insert(T& aElem);

    also int -> T&

    Und das verwirrt mich, wann muss der datentyp zu T und wann zu T& verändert werden?

    Danke schonmal im voraus.



  • Das ist nur eine Referenz. Oft ist es bei Klassen performanter, wenn man keine Kopie erstellt, sondern nur eine Referenz hat.


  • Mod

    Es gibt kein Schema-F dafür. Man nimmt das was man braucht. Dazu muss man natürlich die Bedeutung verstehen. Und die lernt man nicht durch das Betrachten von Beispielen ohne jeden Kontext.



  • Anstatt diesen T&'s gehören überall const T&'s hin, anstatt den int's const int's 😉



  • 314159265358979 schrieb:

    Anstatt diesen T&'s gehören überall const T&'s hin,

    Würde ich auch sagen

    anstatt den int's const int's 😉

    Top-Level const in Parametertypen ist egal.
    Verändert nichtmal die Signatur.
    Anders gesagt, es ist OK eine Funktion z.B. mit

    void foo(int param);
    

    zu deklarieren und dann mit

    void foo(int const param)
    {
    }
    

    zu definieren.

    Was sich ändert ist lediglich ob man den Parameter innerhalb der Definition von foo ändern kann oder nicht. Spielt aber für den Aufrufer keine Rolle.



  • Okay, das ist selbst mir neu. Ich dachte man kann an die Funktion mit int keine const ints übergeben?



  • Wilky schrieb:

    also int -> T&

    Und das verwirrt mich, wann muss der datentyp zu T und wann zu T& verändert werden?

    Wie schon erwähnt wurde macht T& keinen grossen Sinn, wenn dann T const& (bzw. const T& was aber nur ne andere Schreibweise ist).

    Der Unterschied ist dass einmal kopiert wird ( int , T ), und einmal nicht ( int const& , T const& ).

    Bei einem Integer ist es egal, bzw. ist es sogar besser ihn zu kopieren, da eine Referenz auf einen Integer meistens langsamer ist als ihn direkt zu kopieren.

    Bei beliebigen Datentypen ist es aber meist besser eine Referenz zu übergeben, denn bei Typen wie z.B. std::string ist das Kopieren sicher langsamer als der (vergleichsweise kleine) Overhead den die Referenz verursacht.

    Das ganze ist allerdings nicht nur bei Templates relevant. Man sollte auch bei ganz normalen Funktionen die z.B. Strings als Parameter nehmen diese als Referenz-auf-const übergeben (also std::string const& param statt einfach nur std::string param ). Wo es auch oft vergessen wird sind Smart-Pointer, z.B. std::shared_ptr<T> . Die sind zwar hübsch klein, aber trotzdem vergleichsweise sehr langsam zu kopieren (-> die atomaren Instruktionen die dazu nötig sind sind auf den allermeisten Systemen richtig teuer).



  • 314159265358979 schrieb:

    Ich dachte man kann an die Funktion mit int keine const ints übergeben?

    Doch, bei Kopien konnte man schon immer CV-Qualizierer entfernen. Wieso auch nicht, const soll ja nur verhindern, dass ein Objekt (und nicht Kopien davon) verändert werden.



  • 314159265358979 schrieb:

    Okay, das ist selbst mir neu.

    *kicher*



  • hustbaer schrieb:

    314159265358979 schrieb:

    Okay, das ist selbst mir neu.

    *kicher*

    Was willst du damit ausdrücken? Entweder habe ich es nicht bewusst wahrgenommen, oder eben noch nicht verwendet. Ich denke eher das erstere.



  • 314159265358979 schrieb:

    hustbaer schrieb:

    314159265358979 schrieb:

    Okay, das ist selbst mir neu.

    *kicher*

    Was willst du damit ausdrücken?

    Das dir so einiges nicht bekannt ist.



  • Ich denke, mit meinen 15 Jahren bin ich jung genug, dass mir einiges noch nicht bekannt sein darf.



  • Ich denke, mit deinen 15 Jahren solltest du dann keine Sätze wie "das ist selbst mir neu" schreiben.

    Die Formulierung impliziert nämlich, dass es sehr erstaunlich ist, dass es dir neu ist. Und diese Implikation fand ich einfach zum kichern.
    Streiche das "selbst" aus dem Satz, und er ist vollkommen OK.
    (Tip: das "selbst" bedeutet in der Konstellation "sogar", nicht "selbst" im Sinn von "ich selbst")



  • Okay, einverstanden 🙂



  • hustbaer schrieb:

    Ich denke, mit deinen 15 Jahren solltest du dann keine Sätze wie "das ist selbst mir neu" schreiben.

    Die Formulierung impliziert nämlich, dass es sehr erstaunlich ist, dass es dir neu ist. Und diese Implikation fand ich einfach zum kichern.
    Streiche das "selbst" aus dem Satz, und er ist vollkommen OK.
    (Tip: das "selbst" bedeutet in der Konstellation "sogar", nicht "selbst" im Sinn von "ich selbst")

    Ich denke, das war selbst ihm neu. 😃


Log in to reply