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

in main.cpp
Roboter RobObj;

"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 ...

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 ...

MfG Kimmi

#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.

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!

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