Problem mit dateiübergreifener globaler Variable



  • High!

    Es kann natürlich sein, dass mein C++-Lehrbuch (von 1997) längst weggetauter Schnee von vorgestern ist und mein Problem schlichtweg seine Ursache darin hat, dass es nach heutigem ANSI/ISO-Standard gar nicht mehr möglich ist, so zu arbeiten...

    Also: ich ackere mich im Moment gerade durch Ulrich BREYMANN: C++, Eine Einführung, Hanser 1997, S. 127, Kapitel 4.3.3. Dateiübergreifende Gültigkeit und Sichtbarkeit.
    Dort werden als Beispiele diese zwei kleinen Programme aufgeführt:

    // Datei1.cc
    int global;
    int main()
    {
    global=17;
    }

    // Datei2.cc
    extern int global;
    int func1( )
    {
    global=123;
    }

    Das Programm "Datei1.cc" ließ sich mit g++ 3.6 problemlos übersetzen; "Datei2.cc" war aber entgegen der Beschreibung im Buch keineswegs "allein übersetzbar", sondern produzierte bei Kompilieren folgende Fehlermeldungen:

    /tmp/ccjGrB8L.o: In function func()': /tmp/ccjGrB8L.o(.text+0x5): undefined reference toglobal'
    collect2: ld returned 1 exit status

    Was lief da falsch?



  • *sich am Hinterkopf kratz*
    Öhm... sowas macht Mann/Frau in C++?

    Denke es liegt daran, dass der Compiler schon ganz gerne wissen würde wo deine globale Variable definiert ist. Mit "allgemein übersetzbar" ist wohl eher gemeint, dass du deine erste Datei nicht übersetzen musst damit du die zweite Datei übersetzen kannst.



  • Also mal ganz grundsaetzlich: globale Variablen sind ein fast absolutes No-No. Sie verdecken den tatsaechlichen Datenfluss und erzeugen unnoetige Abhaenigkeiten. Wenn eine Funktion/Methode eine Variable benoetigt, dann sollte man sie auch ordentlich als Parameter uebergeben.



  • High!

    MBCS-CITP schrieb:

    Also mal ganz grundsaetzlich: globale Variablen sind ein fast absolutes No-No. Sie verdecken den tatsaechlichen Datenfluss und erzeugen unnoetige Abhaenigkeiten. Wenn eine Funktion/Methode eine Variable benoetigt, dann sollte man sie auch ordentlich als Parameter uebergeben.

    In den 90ern, als mein Lehrbuch verfasst wurde, galt sowas aber anscheinend noch als akzeptabler Stil...

    Wo stelle ich denn beim g++ die Umgebungsvariablen ein, damit der Compiler externe Variablen findet? Irgendwas mit /etc/gcc bzw. /etc/g++ ?

    Bis bald im Khyberspace!

    Yadgar



  • Wo stelle ich denn beim g++ die Umgebungsvariablen ein, damit der Compiler externe Variablen findet? Irgendwas mit /etc/gcc bzw. /etc/g++ ?
    

    Ich glaube da verwechselst du was.. Das hat überhaupt gar nix mit den Umgebungsvariablen zutun.

    Genauso vergessen kannst du das mit dem Schnee von gestern. Das was im Ulrich BREYMANN sollte auch heute noch funktionieren (es sei denn es war schon damals ein Fehler).

    Zu dem akzeptablen Stil: Sowas war in C++ nie aktzeptabel. Das sowas geht, hat damit zutun, dass es mit einem aktuellen C++-Compiler möglich sein soll alte C-Programme übersetzen zu können. Daher wird noch sehr viel Zeug im Standard mitgeschlept, die ein guter C++-Programmierer wenn es möglich ist nicht benutzt.
    Was nichts daran ändert das man wissen sollte, dass sowas geht und deshalb stehts auch in deinem schlauen Buch.

    Bist du dir sicher, dass der Compiler diese Fehlermeldung bringt? Wenn bereits die *.o-Datei existiert hat der Compiler eigentlich schon seinen dienst ohne zu meckern getan.
    Mit diesen Dateien arbeitet der Linker und dieser braucht die beide *.o-Dateien um das Programm erzeugen zu können, da er die Verbindung zwischen den Dateien herstellt.


Anmelden zum Antworten