3. Linker-Fehler "Unresolved external"

Linker-Fehler "Unresolved external"

  • S

    HAllo,

    ich verwende bisher den Borland Builder 5, brauche dort ein Zusatzprogramm (oder besser gesagt Zusatzklassen) für die Benutzeroberfläche dort, das nur mit dem Borland Builder läuft. Ich benutze dieses und die Borland Builder-GUI.
    Nun will ich das Programm in der jetzigen Entwicklungsphase vermehrt auf einem anderen Rechner laufen lassen, wo das GUI und der Borland Builder nicht verfügbar sind. Kann aber schon gut sein, daß ich bei weiteren Entwicklungsschritten des Programms wieder auf diese GUI des Borland Builders zurückgreifen muß und es wieder auf meinem Rechner laufen lasse.
    Sprich: Ich möchte zwischen verschiedenen Compilern (und v.a. GUI j/n) möglichst einfach hin- und herwechseln können.
    ICh hab mir dafür eine Dummy-GUI-Klasse ausgedacht, die alle Methoden der richtigen GUI hat, aber eben nichts machen. Dann noch eine main-Fkt. dazu, die den Code (bis auf den GUI-KRam) enthält, der bisher in der Fkt. der GUI stand, mit der mein eigentliches Programm gestartet wurde.
    NUn hab ich das gemacht und kriege jede Menge Linker-Fehlermeldungen "Unresolved external" von anderen Klassen in meinem Projekt (auch nach auskommentieren der Dummy-GUI-Methoden und deren Verwendung). Nur hatte das vorher ja alles einwandfrei funktioniert. Hat jemand eine Idee, nach was ich suchen muß? (falls dafür irgendwelcher COde von mir nötig ist, würde ich mal gucken, wie ich das so kürzen kann, daß man es trotzdem versteht)

    Danke sehr!

    0
  • P

    Wenn du den Code auf dem anderen Rechner nochmal komplett neu compilierst und die ganzen Funktionen der Dummy-GUI auch eine Definition haben sollte es eigentlich kein Problem geben.

    0
  • S

    Ja, so dachte ich es mir ja auch. Aber dann müßte es ja auch auf meinem jetzigen Rechner, eben ohne Verwendung der GUI, übersetzen. Tut es aber nicht...

    0
  • Mod

    NUn hab ich das gemacht und kriege jede Menge Linker-Fehlermeldungen "Unresolved external" von anderen Klassen in meinem Projekt (auch nach auskommentieren der Dummy-GUI-Methoden und deren Verwendung).

    Dann ist es wohl etwas anderes als deine GUI, das fehlt. Bei der Fehlermeldung müsste dabeistehen, was nicht vorhanden ist.

    0
  • S

    Ich hab jetzt mal ganz viel auskommentiert, die main in ein extra-File geschrieben (dadurch haben sich die Fehlermeldungen auf zwei reduziert) und gebe das hier mal zum Besten (vielleicht ist inzwischen auch bei der vielen Auskommentiererei irgendwas verloren gegangen):

    File1.cpp:

    #include "controller.h"

extern DummyGUI *gui_ptr;
extern Controller *contr_ptr;

int main() {
    Controller controller;
    string dummy;
    gui_ptr=new DummyGUI();
    contr_ptr=&controller;
    //controller.start();
    delete gui_ptr;  
    return 0;  
}

    controller.h:

    #ifndef controllerH
#define controllerH

//#include "Start.h"  //FürGUI

//etliche include-Anweisungen von Dateien für andere klassen weggelassen

class DummyGUI {
};

class Controller {
};
#endif

    controller.cpp:

    #include "controller.h"
extern DummyGUI* gui_ptr;  
extern Controller *contr_ptr;

    globalVariables.cpp:

    DummyGUI* gui_ptr; 
Controller *contr_ptr;

    Die Fehlermeldungen lauten:

    Unresolved external '_contr_ptr' referenced from ...File1.obj
Unresolved external '_gui_ptr' referenced from ...File1.obj

    Ich dachte, das wäre richtig so, ohne "extern" in globalVariables.cpp, mit "extern" überall sonst, wo die Variablen verwendet werden?! Oder ist es was anderes?

    Danke und viele Grüße

    0
  • ?

    susie schrieb:

    #include "controller.h"
extern DummyGUI* gui_ptr;  
extern Controller *contr_ptr;

    globalVariables.cpp:

    DummyGUI* gui_ptr; 
Controller *contr_ptr;

    Die Fehlermeldungen lauten:

    Unresolved external '_contr_ptr' referenced from ...File1.obj
Unresolved external '_gui_ptr' referenced from ...File1.obj

    Ah da drückt der Schuh...
    Du musst den pointer schon mit new initialisieren. Aber pointer macht mMn mit extern wenig Sinn.

    Am besten machst du dir nen Header "globalVariables.h", in dem kommt

    extern DummyGui gui;
extern Controller ctrl;

    und in einer globalVariables.cpp dann

    DummyGui gui;
Controller ctrl;

    Aber ich bin mit so nem extra Unit für globale Variablen nicht glücklich. Ich möchte diese haben, wenn ich ein DummyGui.h einbinde. Darum lass das mit der globalVariables-Unit und pack alles in diepassenden.

    0
  • P

    oder su lässt das mit den Globalen variablen ganz und schreibst dir eine Klasse die die Dinger verwaltet - dann kannst du auch sicher sein, dass sie initialisiert worden sind bevor du von einem anderen Modul drauf zugreifst.

    0
  • S

    Also, ich hab das Problem gelöst: ICh mußte nur im Borland Builder ein neues Projekt als Konsolenanwendung definieren und die ganzen DAteien neu zufügen. Ich dachte, wenn ich allen GUI-Kram rauslösche, das Projektfile lösche und der BB einen fragt, ob er ein neues Projekt erzeugen will, macht er es automatisch richtig.
    Nun gut, jetzt läuft es zwar noch nicht so, wie es soll, aber nachdem ich eben wie ne Wilde rumgelöscht und auskommetiert habe, muß ich nur ein bißchen Ordnung reinbringen, dann wird das schon.

    Was das mit den globalen Variablen angeht:
    pumuckl, wie meinst Du das mit ner Klasse, die sie verwaltet? KAnn mir darunter nicht so viel vorstellen...
    Also ich brauche so ungefähr 4-5 globale Variable, von denen die meisten zu Anfang initialiert und dann während des Programmlaufs nicht mehr verändert werden (oder ganz simpel in einer Schleife ganz äußeren Schleife immer wieder neu erzeugt werden)

    0
Anmelden zum Antworten