C++ Template Klasse



  • Hallo Leute,

    ich wollte euch fragen wie ihr bei der Implementation einer Template-Klasse vorgeht?

    Ich benutze die GNU Compiler Collection und mir scheint das der g++ ein Template nicht in eine .so (oder .dll unter Win) packen kann. Ist ja nach Stroustrup auch so gewollt aber trotzdem schade.

    Daher hole ich die Header- und Source-Dateien jedesmal per "#include" in meinen Code rein.

    Daher meine Fragen:

    Trennt ihr Header- und Source-Dateien (bzw. .h und .cpp)?

    Und wenn ja, wo packt ihr die Source-Dateien hin? Ins selbe Verzeichnis wie die Header-Dateien? Unter Unix ist das bei mir das "/usr/include"-Verzeichnis.

    Besten Dank

    Goran



  • goran schrieb:

    Ich benutze die GNU Compiler Collection und mir scheint das der g++ ein Template nicht in eine .so (oder .dll unter Win) packen kann. Ist ja nach Stroustrup auch so gewollt aber trotzdem schade.

    Daher hole ich die Header- und Source-Dateien jedesmal per "#include" in meinen Code rein.

    Das ist auch voellig richtig so. Templates sind nur Schablonen, aus denen der Compiler automatisch Code erzeugt wenn der Code gebruacht wird. Daher kann aus template-definitionen anders als bei normalen Klassen udn Funktionen nicht von vornherein Code erzeugt werden, der in eine Objektdatei gepackt werden koennte. Der Code fuer Klassentemplates wird erst dann erzeugt, wenn das template irgendwo instantiiert wird. In dem Sine koennte man sagen, dass es fuer templates garkeine richtigen Source-Dateien gibt und eigentlich alles in den Header geschrieben werden kann/sollte. Es gibt drei leicht unterschiedliche Vorgehensweisen:

    1. Schreibe die Definitionen von Methoden bei Klassentemplates gleich in die Definition der Klasse. Du erhaelst eine einzelne Headerdatei, die bei groesseren Klassen allerdings relativ unuebersichtlich sein kann.
    2. Schreibe die Definitionen wie gewohnt in eine gesonderte "Source"-Datei. Da du diese aber sowieso immer mit #includen musst, bindest du sie gleich am Ende der Headerdatei ein.
    3. Schreibe die Definitionen der Methoden gleich hinter die Klassendefinition mit in den Header, das hat den gleichen Effekt wie bei 2), nur laesst man die "source"-datei weg.
    //Variante 1)
    //=======================
    template <class T>
    class Beispiel {
    public:
      void foo() {cout << "juhu";}
    };
    
    //Variante 2)
    //==beispiel.hpp==========
    template <class T>
    class Beispiel {
    public:
      void foo();
    };
    #include beispiel.ctp
    //==beispiel.ctp==========
    template<class T>
    void Beispiel<T>::foo()
     {cout << "juhu";}
    
    //Variante 3)
    //==========================
    template <class T>
    class Beispiel {
    public:
      void foo();
    };
    
    template<class T>
    void Beispiel<T>::foo()
     {cout << "juhu";}
    


  • Vielen Dank für die ausführliche Antwort. Ich war mir bisher unsicher welche Methoden genutzt werden.

    Beste Grüße, Goran



  • Kleiner Nachtrag: Nicht erwaehnt habe ich das Schluesselwort export , das im Standard vorgesehen ist um sowas aehnliches wie die Trennung von Deklaration und Definition bei templates vorzunehmen, aber eben nur sowas aehnliches. Hab da in nem Buch (ich meine es war Sutter/Alexandrescu::C++ coding Styles) was drueber gelesen, in der Kurzform hiess es da in etwa:
    - export tut nicht das, was man sich eigentlich naiv drunter vorstellt
    - es wird nur von einem Compiler unterstuetzt
    - wirklich besser als das inclusion model (was wir alle kennen, siehe oben) ist es auch nicht
    => nice to know, mehr aber auch nicht, da praktisch nicht anwendbar.



  • pumuckl schrieb:

    Kleiner Nachtrag: Nicht erwaehnt habe ich das Schluesselwort export , das im Standard vorgesehen ist um sowas aehnliches wie die Trennung von Deklaration und Definition bei templates vorzunehmen, aber eben nur sowas aehnliches. Hab da in nem Buch (ich meine es war Sutter/Alexandrescu::C++ coding Styles) was drueber gelesen, in der Kurzform hiess es da in etwa:
    - export tut nicht das, was man sich eigentlich naiv drunter vorstellt
    - es wird nur von einem Compiler unterstuetzt
    - wirklich besser als das inclusion model (was wir alle kennen, siehe oben) ist es auch nicht
    => nice to know, mehr aber auch nicht, da praktisch nicht anwendbar.

    Und der Compiler, der das unterstützt ist Comeau.
    Nur so als ergänzende Info. 😉


Anmelden zum Antworten