Merkwürdiges Verhalten von G++ (GCC)



  • Hallo,

    bei mir ist etwas komisches aufgetreten. Ich habe folgende Klasse Implementiert:

    /*
     * DeugLog.h
     */
    //...
    class DebugLog
    {
      public:
        //...
        template<typename T> DebugLog& operator<<( const T& out )
        {
            // output to console
            if( log_to_console )
                cout << out;
            // output to log file
            if( log_to_file == true )
                file << out;
            return *this;
        }
        //...
    };
    

    Wenn ich jetzt den Code von operator<< nach DebugLog.cc verfrachte...

    /*
     * DebugLog.cc
     */
    //...
    template<typename T> DebugLog& DebugLog::operator<<( const T& out )
    {
        // output to console
        if( log_to_console )
            cout << out;
        // output to log file
        if( log_to_file == true )
            file << out;
        return *this;
    }
    //...
    

    ... erhalte ich folgende Fehlermeldung:

    rm -f *~ DebugLog.o debug.o debug
    g++ -g -Wall -O2 -I. -c DebugLog.cc
    g++ -g -Wall -O2 -I. -c debug.cpp
    g++ -g -Wall -O2 DebugLog.o debug.o  -o debug
    debug.o: In function `basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::replace(unsigned int, unsigned int, char const *, unsigned int)':
    /usr/include/g++/stl_alloc.h:157: undefined reference to `DebugLog & DebugLog::operator<<<char [5]>(char [5] const &)'
    collect2: ld returned 1 exit status
    make: *** [all] Fehler 1
    

    Um alle Klarheiten zu beseitigen, hier meine Testfunktion:

    /*
     * debug.cpp
     */
    #include "DebugLog.h"
    using namespace std;
    int main() {
        DebugLog debug;
        debug.init( DEB_LEV_INF );
        debug << "Test " << endl;
        return 0;
    }
    

    Was ist denn Da los?

    Viele Grüße
    Bastian

    P.S.:
    Ich verwende g++ Version 2.95.3



  • Hallo,
    das ist keine Macke im gcc, sondern prinzipbedingt.
    Die Definitionen von Templates müssen in jeder ÜE sichtbar sein, in der sie verwendet werden. Bedenke, dass der Compiler für ein Template konkrete Instanzen erzeugen muss. Das kann er aber nur, wenn er die Definition des Templates hat.

    Schau auch nochmal hier:

    http://www.c-plusplus.net/forum/viewtopic.php?t=39467



  • merke dir eins: der compiler ist nie schuld
    (ok stimmt nicht ganz, aber in 99,9%)



  • HumeSikkins schrieb:

    Hallo,
    das ist keine Macke im gcc, sondern prinzipbedingt.
    Die Definitionen von Templates müssen in jeder ÜE sichtbar sein, in der sie verwendet werden. Bedenke, dass der Compiler für ein Template konkrete Instanzen erzeugen muss. Das kann er aber nur, wenn er die Definition des Templates hat.

    Schau auch nochmal hier:

    http://www.c-plusplus.net/forum/viewtopic.php?t=39467

    Vielen Dank,

    das hat geholfen. Ich habe die Templatemethoden jetzt inline implementiert.
    Beim g++ Version 3.3 geht es aber auch ohne, genauso wie ich es machen wollte. Da ich aber momentan noch nicht überall ein g++ v3.3 zur Verfügung habe bleibe ich momentan erst einmal bei der Inline-Methode.

    Vielen Dank
    Bastian



  • Beim g++ Version 3.3 geht es aber auch ohne

    Auch noch, wenn weitere cpp-Dateien hinzukommen?
    Also z.B.

    debug.h
    debug.cpp -> Enthält die Definitionen des Templates
    a.cpp -> Inkludiert debug.h und verwendet die Template-Funktionen mit Typ A
    main.cpp -> Inkludiert debug.h und verwendet die Template-Funktionen mit Typ B

    Das das funkioniert, möchte ich doch sehr bezweifeln.



  • Okay okay, Deine Zweifel sind berechtigt, auch bei g++ v3.3 geht das nicht :(.

    Viele Grüße
    Bastian



  • Hallo,

    falls es von interesse ist, der neue Borland Compiler wird export unterstuetzen.

    Hoffe die gcc auch bald 🙂

    mfg
    v R



  • falls es von interesse ist, der neue Borland Compiler wird export unterstuetzen.

    Was aber nichts an der Tatsache ändert, dass du den Quellcode der Templates mit ausliefern musst. export verringert keine Abhängigkeiten. export versteckt sie nur ein wenig.
    Wer mehr dazu wissen will:
    Export Restrictions, Part 1

    [url=http://www.gotw.ca/publications/mill24.htm]Export Restrictions, Part 2
    [/url]

    Wer mehr über einen anderen interesanten Ansatz wissen will:
    http://www.cuj.com/documents/s=8188/cuj0310niebler/


Anmelden zum Antworten