objekt global erreichbar



  • Hallo,

    wie shcaffe ich es, das ein Objekt global überall in verschiedenen .cpp files erreichbar ist.

    Folgendes habe ich gebaut:
    In der main.h erstelle ich die Klasse.
    die main.h ist in der main.cpp und test2.cpp included.
    wenn ich jetzt in der main.cpp das objekt erstelle, ist es in test2.cpp nicht erreichbar.
    Den Wert Roboter1.Attack bräuchte ich in der test2.cpp. Wie kann ich das erreichen, dass die Roboter1 überall ansprechbar ist?

    //main.cpp
    int main() {
    //...
    RoboTron Roboter1;
    Roboter1.Attack = 1;
    //...
    }
    
    #ifndef MAIN_H
    #define MAIN
    
    class RoboTron {
    public:
    int posX;
    int posY;
    int posZ;
    float TopSpeed;
    float CurrSpeed;
    float Waypoints[6];
    float WaypStatus[6];
    int Energy;
    int Attack;
    int Exist;
    float Degree;
    };
    #endif
    

    Wenn ich in der main.h

    RoboTron Roboter1;
    

    verwende kommt immer, dass roboter1 doppelt deklariert ist, logisch, wird ja zweimal aufgerufen einmal durch main.cpp und test2.cpp.

    Vielen dank für Eure Hilfe
    Edwart



  • im header:
    extern Roboter RobObj;

    in main.cpp
    Roboter RobObj;



  • und nu bitte 50 mal an die tafel schreiben:

    "globale variablen sind poese !" ^^

    - Schau ob du die zwingende Globale Variable wegbekommst .... zu 60% braucht man die meist ned wirklich global.
    - wenn du es nicht schaffst, gibt es meist noch andere anforderungen an die variable (lifecycle beachten !!!), dann schlagen andere techniken zu (singleton)
    - wenn dir das alles zu kompliziert ist, versteck die variable wenigstens hinter ner klasse (static member) und oder namespace.

    (jeder faengt mal an, aber man soll sich sowas gar ned erst angewoehnen !!! )

    Ciao ...



  • naja, ich finde zB sinnvoll, in einem Programm einen globalen zeiger auf die Anwendungsklasse zu haben



  • Für was?



  • Für was?

    Bei komplizierteren frameworks erspart man sich schon einiges dadurch ^^

    z.b.
    wenn jede fensterklasse nen handle auf die App braucht ... kann man nicht so ohne weiteres die fensterhirarchie auf die objecthirarhie abbilden.
    gibt ja fenster die kein parent fester haben, aber trotzdem teil der application sind.

    die Alternative waere, jedem konstruktor das app object mitgeben ....
    und so "schoene" statische MessageBox methoden gaengen ned mehr.

    ich persoenlich waere ja auch fuer die alternative, aber viele andere programmierer halt nich ^^

    ich finde zB sinnvoll

    Es gibt durchaus dinge wo es sinnvoll ist ... z.b. nn globaler Logger, timer ... etc. wo das durchschleifen durch die aufrufhirarchien nur im chaos enden wuerd.

    Aber wie gesagt solche dinge haben meist auch noch andere anforderungen, z.b Ihre einzigartigkeit (Singleton) und an die laufzeit (wenn mehrere globale objekte, in welcher reihenfolge werden die erzeugt und zerstoert ??? )
    Die technik dazu basiert meist auch auf ner globalen variable ... aber keine die leuchtet wie ne 1000 watt halogenbirne im Quellcode ^^
    "versteckte" globale veriablen sind z.b. statische member in klassen ... und da motzt keiner. Das problem an ner globalen variable iss ja auch nicht so das global oder namenskonflikte, sondern der ungescheutzte zugriff von ueberall her ...

    und nur weil die mfc und die Qt daran festhalten (die moegen ja noch nich mal namespaces !!! ) muss mir das ja nicht gefallen ^^

    ciao ...



  • Globale Logger, Timer etc. lassen sich alle wesentlich eleganter über einen Singleton implementieren, wobei man dann auch je nach Design das Problem mit dem Releasen der Objekte gestaffelt nach Deps. kapseln kann. Allein deswegen schon: globale Objekte == BÖSES ZEUG!!!

    MfG Kimmi



  • Das könnte Dir mal zum Stolperstein werden :

    #ifndef MAIN_H
    #define MAIN
    

    besser wäre :

    #ifndef MAIN_H
    #define MAIN_H
    

    Sehen die anderen Include-Guards ähnlich aus ?

    Zumal sehe ich bei Deiner Klasse keinen Konstruktor, welcher Deinen Variablen anfangswerte zuweist.

    Ich persönlich mache meine Variablen immer private und arbeite mit Zugriffsfunktionen. Das ist aber Geschmackssache.



  • muh schrieb:

    Ich persönlich mache meine Variablen immer private und arbeite mit Zugriffsfunktionen. Das ist aber Geschmackssache.

    Nein ist es nicht. Membervariablen, die public sind, zerschießen dir die Datenkapselung. Das ist böse und unter allen Umständen zu meiden!



  • muh schrieb:

    Ich persönlich mache meine Variablen immer private und arbeite mit Zugriffsfunktionen. Das ist aber Geschmackssache.

    Manchmal wünsche ich mir sowas wie die Get- und Set-Funktionen von C# :p


Log in to reply