Eine ganz blöde Frage:

Wie legt man in Visual Studio eigentlich 'richtig' - also so, wie es von den VS Autoren gedacht wurde - globale Variablen an? Ich habe in der GUI nämlich noch keine Möglichkeit dazu gefunden: Im Kontextmenü einer Klasse gibt es zwar "Add Variable", aber dort gibt es nur die Möglichkeiten public, protected und private.
(OK, eine globale Variable ist ja auch kein Klassenmember, aber eine andere Möglickeit zum Hinzufügen von Variablen per GUI ist mir noch nicht begegnet, es kommt immer nur der "Add Member Variable Wizard")
**
Bisher setzte ich daher globale Variablen immer von Hand hinter den include Teil, entspricht das so den Regeln der Kunst?**
(Und ist es egal, ob ich sie in den Header .h oder gleich in die .cpp Datei schreibe?)

Bisher funktioniert es jedenfalls, bis auf eine ärgerliche Einschränkung:
**
Ich kann im ganzen Projekt jeden Namen einer globalen Variable nur einmal verwenden, sonst gibt es einen Error LNK2005.**
Z.B.:

ZahlenhaufenIteration.obj : error LNK2005: "class C3DFenster * tuf" (?tuf@@3PAVC3DFenster@@A) already defined in TuringIteration.obj

Kann man das irgendwie vermeiden?
Ich habe zwar einiges über LNK2005 gefunden, aber das scheint hier nicht zu passen. (Häufige Empfehlung: gezieltes Entfernen einer Libary....)

Danke und Gruß,
dong

extern CString m_sStringGlobal;

deklarieren. in der jeweiligen *.cpp (ich machs wenn dann in der stdafx.cpp)

CString m_sStringGlobal;

wieder auflösen und somit kannst du die in jeder classe in deinem project verwenden.

Ich kann im ganzen Projekt jeden Namen einer globalen Variable nur einmal verwenden

naja ist doch klar oder du kannst auch nicht in einer classe ne variablennamen 2 mal verwenden. das gleiche gilt dann auch für global.

mfg
LowFly

Wenn ich recht verstehe, redest Du von globalen Variablen, die im ganzen Projekt gültig sind. (Ich kenne auch die entsprechende FAQ Seite, ich benutzte schließlich die Suche und schaute in die FAQ...;) )
Die meine ich nicht, ich meinte etwas weniger global:

Ich meine globale Variablen, die innerhalb einer .cpp Datei (inkl. Header) gültig sind.

So, wie ich das bisher machte, funktionierte das auch:

Man betrachte die Klassen CBeispiel1 und CBeispiel2, bestehnd aus den Dateien Beispiel1.cpp, Beispiel1.h, Beispiel2.cpp und Beispiel2.h.

Die globalen Variablen, die ich meine, kann ich so anlegen:

//Besipiel1.cpp:
#include "Beispiel1.h"

//"meine" globale Variable:
int test1;

oder eben auch:

//Beispiel2.h:
//"meine" globale Variable:
int test2;
...
//Beispiel2.cpp:
#include "Beispiel2.h"
...

Dann kann ich von allen Funktionen in Beispiel1.cpp auf test1 und in allen Funktionen in Beispiel2.cpp auf test2 zugreifen, aber eben nicht umgekehrt.
Und soweit ist das auch erwünscht.

Nicht erwünscht ist hingegen, dass ich in Beipiel1.cpp und in Beispiel2.cpp nicht den gleichen Namen für diese Art globale Variable verwenden darf, dann kommt eben der blöde LNK2005 Error:

//Besipiel1.cpp:
#include "Beispiel1.h"

//"meine" globale Variable:
int test;

//Besipiel2.cpp:
#include "Beispiel2.h"

//"meine" globale Variable:
int test;

geht deshalb eben nicht.

Und das ist (eine meiner zwei) Frage(n): Wie kann ich dafür gleiche Namen verwenden (die Variablen haben ja schließlich verschiedene Gültigkeitsbereiche!), aber LNK2005 vermeiden?

Danke und Gruß,
dong

P.S.:
Warum globale Variablen und nicht Membervariablen?
Für mindestens zwei Dinge:

1. Ich verwende Threadfunktionen, von denen man nicht direkt auf alle Membervariablen zugreifen kann, da Threadfunktionen statische Funktionen sein müssen. Daher behelfe ich mir mit dem Trick, dass ich globale Zeiger benutze um auf Membervariablen vom Thread aus zuzugreifen.
2. Für Nummerierungen mit enum: Das sind zwar nicht direkt globale Variablen, aber für sie gelten die ähnliche Probleme:
   z.B.

//Beispiel1.h
enum Randbedingungen
{
	fest, offen, periodisch
};

//Beispiel2.h
enum Randbedingungen2
{
	fest, offen, periodisch
};

führt zu einem ähnlichen Error:

error C2365: 'fest' : redefinition; previous definition was 'enumerator': see declaration of 'fest'

Aber zugegeben, die sind wohl doch ein anderes paar Steifel und die könnte ich vielleicht wirklich in LowFlys Sinne global anlegen, mal gucken, ob das klappt...

weil man es ja class.m_variable oder class->m_variable aufruft. alles was nun auserhalb einer classe liegt steht in einem globalen bereich der durch nichts geschützt wird. somit passiert also genau das gleiche wie wenn du in einer classe ein & dieselbe variable 2 mal definierst.

wenn ich das bisher richtig verstanden hab dann macht der compiler keinen unterschied zwischen A.h, A.cpp & B.h, B.cpp das sind für den nur dateien die er nacheinader einliest & aus 5 verschiedenen dateien 1 große macht.

steht jetzt in A.cpp auserhalb einer classe ne deklaration zb.

CString m_sGlobal;

kann diese nur in der A.cpp angesprochen werden steht aber im gloabalne bereich der durch nix geschützt ist (classe).
deklarierst du nun in B.cpp die selbe variable nochmal, steht sie für dich scheinbar in einer anderen datei aber für den compiler nicht.

setzt du nun das extern vor die variable

extern CString m_sGlobal;

sagst du dem compiler nur damit das diese variable für alle anderen dateien die er einliest, die nach der folgen in der du sie deklariert hast, gültig ist und diese benutzt werden darf. (Anbei es spielt keine rolle ob du globale variable in der *.cpp o. *.h auserhalb einer classe deklarierst.)

beide deklarationen mit und ohne extern stehen aber in dem selben globalen bereich der wie eine classe behandelt wird.

aus diesem grund denke ich passiert der fehler.

hoffe es stimmt so wie ich es erklärt hab, wenn nicht bitte berichtigen
mfg
LowFly

wenn ich das bisher richtig verstanden hab dann macht der compiler keinen unterschied zwischen A.h, A.cpp & B.h, B.cpp das sind für den nur dateien die er nacheinader einliest & aus 5 verschiedenen dateien 1 große macht.

steht jetzt in A.cpp auserhalb einer classe ne deklaration zb.

CString m_sGlobal;

kann diese nur in der A.cpp angesprochen werden steht aber im gloabalne bereich der durch nix geschützt ist (classe).
deklarierst du nun in B.cpp die selbe variable nochmal, steht sie für dich scheinbar in einer anderen datei aber für den compiler nicht.

setzt du nun das extern vor die variable

extern CString m_sGlobal;

Ah ja, jetzt verstehe ich sowohl besser, was der Compiler macht, als auch besser, was der extern Vorschlag in der stdafx.h sollte.

Nur eins verstehe ich dann noch nicht:

in der jeweiligen *.cpp (ich machs wenn dann in der stdafx.cpp)

CString m_sStringGlobal;

wieder auflösen und somit kannst du die in jeder classe in deinem project verwenden.

Was heißt hier "auflösen"?

Danke und Gruß,
Dong

extern CString m_GlobalString;

schreibst und die variable m_GlobalString zb in deinem Dialog wie unten folgt verwendest

CDialog::OnInitDialog()
{
    m_GlobalString = "Ich bin eine globale Variable";
    MessageBox(m_GlobalString);
....
}

OHNE sie vorher in diesem fall in der Dialog.cpp oberhalb der classe wie folgt aufzulösen.

CSting m_GlobalString;

ich mach das halt immer in der stdafx.h / .cpp da dies eine der ersten dateien ist die der compiler einliest bzw. diese in jeder datei als erste als include stehn. somit brauch ich mir dann keine gedanken mehr machen hab ich sie nun aufgelöst oder nicht & wenn ja wo. die stdafx sehen alle classen somit gloabal.

mfg
LowFly

dong schrieb:

P.S.:
Warum globale Variablen und nicht Membervariablen?
Für mindestens zwei Dinge:

1. Ich verwende Threadfunktionen, von denen man nicht direkt auf alle Membervariablen zugreifen kann, da Threadfunktionen statische Funktionen sein müssen. Daher behelfe ich mir mit dem Trick, dass ich globale Zeiger benutze um auf Membervariablen vom Thread aus zuzugreifen.

Du kannst einem Thread aber auch einen Zeiger übergeben. Daher muss das Zeugs nicht immer über Globale Variablen gehen. Ich würde sowieso vorschlagen, dies gerade nicht zu tun. Wie kannst du nun mehrere Dinge über nur einen Zeiger übergeben? Kein Problem:

struct SGiveThread
{
    int nInt;
    float fFloat;
    CString strName;
    CEinObjekt* pEinObjekt;
    // usw. oder was auch immer
};

UINT CDeineKlasse::ThreadFunction(LPVOID pParam)
{
    SGiveThread* pGiveThread = static_cast<SGiveThread*>(pParam);

    // pGiveThread auslesen.

    // Speicher freigeben.
    delete pGiveThread;
}

void CDeineKlasse::StartThread()
{
    SGiveThread* pGiveThread = new SGiveThread;

    // pGiveThread füllen.

    AfxBeginThread(CDeineKlasse::ThreadFunction, pGiveThread);
}

dong schrieb:

1. Für Nummerierungen mit enum: Das sind zwar nicht direkt globale Variablen, aber für sie gelten die ähnliche Probleme:
   z.B.

//Beispiel1.h
enum Randbedingungen
{
	fest, offen, periodisch
};

//Beispiel2.h
enum Randbedingungen2
{
	fest, offen, periodisch
};

führt zu einem ähnlichen Error:

error C2365: 'fest' : redefinition; previous definition was 'enumerator': see declaration of 'fest'

Aber zugegeben, die sind wohl doch ein anderes paar Steifel und die könnte ich vielleicht wirklich in LowFlys Sinne global anlegen, mal gucken, ob das klappt...

Jo also, wenn du ein Enum hast mit zweimal dem gleichen Inhalt, da ist es schon sinnvoll, dass du da das gleiche brauchst. Und sonst definier halt einen anderen Namen, wenn es einen anderen Inhalt hat. Oder nimm die Inhalt zusammen und deklarier es nur einmal. Also das Problem wirst du wohl mit einer sinnvollen Strukturierung wegbekommen.

Ajo ... nochwas. Wenn du mehrere Sachen Global anlegst, ist es vielleicht eine Überlegung wert, dass du sie in ein Namespace nimmst.

// stdafx.h
namespace Global
{
    // Irgendwelche Variablen.
}

Aber sowas sollte glaub ich schon in der FAQ stehen ^^

Grüssli

Dravere schrieb:

dong schrieb:

Ich verwende Threadfunktionen, von denen man nicht direkt auf alle Membervariablen zugreifen kann, da Threadfunktionen statische Funktionen sein müssen. Daher behelfe ich mir mit dem Trick, dass ich globale Zeiger benutze um auf Membervariablen vom Thread aus zuzugreifen.

Du kannst einem Thread aber auch einen Zeiger übergeben. Daher muss das Zeugs nicht immer über Globale Variablen gehen. Ich würde sowieso vorschlagen, dies gerade nicht zu tun.

Also:
Wenn ich dem Thread jede Variable, auf die er zugreifen muss, einzeln in einem struct verpackt übergebe, wäre das schon eine ganz schön lange Liste, zumal sich diese Variablen während Ablauf des Threads ändern können, d.h. ich müßte für jede Varaible erst mal einen Zeiger erstellen, damit der Thread Zugriff auf den aktuellen Wert hat.Dann würde ich am besten ja gleich nur Zeiger auf die verwendeten Objekte übergeben (statt auf deren Member). Und dann ist es ja eigentlich nur ein kleiner Unterschied zu meinen globalen (im Sinne von: Geltungsbereich = dateiweit) Zeigern auf eben diese Objekte.
Also der einzige Nachteil, den ich bei meinen gloablen Zeigern auf die verwendeten Objekte erkennen kann ist, dass ich die Threadfunktion nicht so ganz ohne weiteres in eine andere Datei copy&pasten könnte. Aber ansonsten...?

Und zu der Sache mit den Nummerierungen enum:
Das war tatsächlich ganz einfach:
In die stdafx.h damit und fertig, die Nummerierung steht dann überall zur Verfügung (und so ist das auch ganz praktisch für mich...:) )

Gruß,
dong

Diese Kapselung erhöht meiner Meinung nach die Übersicht. Der Code wird lesbarer, man versteht woher welche Informationen kommen.

Noch so als Zusatz: Zur Kommunikation zwischen den Threads sollte man auf CEvent's und PostThreadMessage / PostMessage setzen. Gleichzeitiges schreiben und lesen auf eine Variable, kann böse folgen haben.

Grüssli

Der Vorteil von einem Struct ist eine Kapselung. Die Variablen liegen nicht einfach so frei im nichts rum und sind von jedem aufgreifbar. Du kannst mit einem Struct natürlich Referenzen, Zeiger aber auch Werte/Kopien dem Thread übergeben. Du kannst ja dann auch gleich mit dem Struct-Zeiger im Thread arbeiten und musst nicht zuerst alles rauskopieren oder so.

Ah ja. Da ich alleine programmiere, bin ich eigentlich immer ganz froh, wenn ich auf alles möglich zugreifen kann, aber ich sehe ein, dass das wohl eher schlechter Stil ist.

Dravere schrieb:

Diese Kapselung erhöht meiner Meinung nach die Übersicht. Der Code wird lesbarer, man versteht woher welche Informationen kommen.

Das klingt in der Tat vernünftig....

Dravere schrieb:

Noch so als Zusatz: Zur Kommunikation zwischen den Threads sollte man auf CEvent's und PostThreadMessage / PostMessage setzen. Gleichzeitiges schreiben und lesen auf eine Variable, kann böse folgen haben.

Selbstgemachte CEvens und so kann ich noch nicht. Ist aber nicht so schlimm, bei kritischen Variablen habe ich dafür extra zwei Versionen der selben Variablen angelegt: Die eigentliche Variable und einen Puffer, der Wert des Puffers wird immer nur zu bestimmten, geeigneten Zeitpunkten der Variable übergeben. So sollte es hoffentlich auch erstmal gehen.

Aber wenn ich Zeit habe, werde ich mir die CEvents Geschichte mal näher ansehen, danke für den Hinweis.

dong schrieb:

...
Nicht erwünscht ist hingegen, dass ich in Beipiel1.cpp und in Beispiel2.cpp nicht den gleichen Namen für diese Art globale Variable verwenden darf, dann kommt eben der blöde LNK2005 Error:

//Besipiel1.cpp:
#include "Beispiel1.h"

//"meine" globale Variable:
int test;

//Besipiel2.cpp:
#include "Beispiel2.h"

//"meine" globale Variable:
int test;

geht deshalb eben nicht.

Und das ist (eine meiner zwei) Frage(n): Wie kann ich dafür gleiche Namen verwenden (die Variablen haben ja schließlich verschiedene Gültigkeitsbereiche!), aber LNK2005 vermeiden?

Und zwar geht das folgendermaßen:
Man legt diese Variablen einfach in namespaces:

//Besipiel1.cpp:
#include "Beispiel1.h"

namespace ns_beispiel1
{
    int test;
}
using namespace ns_beispiel1;
...

//Besipiel2.cpp:
#include "Beispiel2.h"

namespace ns_beispiel2
{
    int test;
}
using namespace ns_beispiel2;
...

--> test in Beispiel1 und test in Beispiel2 sind zwei verschiedene, voneinander unabhängige Variablen mit Dateigeltungsbereich, und das ohne LNK2005 Error.

Wohlgemerkt geht das nur dann, wenn man diese Variable innerhalb einer namespae Deklaration in der cpp Datei macht, im Header treten komischerweise trotzdem die LNK2005 Error auf.

Gruß,
Dong

// A.cpp
int test1;

// B.cpp
int test2;

LOL

Grüssli

Tolle Lösung, und wieso ein extra Namespace machen und nicht einfach

// A.cpp
int test1;

// B.cpp
int test2;

Weil ich in meinen Pendants zu Beispiel1 und Beispiel2 um Teil gleiche Codefragmente nutze, die sich so endlich direkt copy und pasten lassen ohne das ich etwas ersetzen müßte. Das Ersetzen (auch mit STRG + h...) scheint mir nämlich mehr Arbeit als die Erstellung der namespaces...

...außerdem habe ich jetzt, da ich die namespaces kennengelernt habe, den Eindruck, dass die Variablen darin sauberer aufgehoben sind, als wenn sie irgendwo frei darum liegen. (Und z.B. möglicherweise viel zu früh angelegt werden, auch, wenn sie noch gar nicht benötigt werden, aber sie werden eben als global (im Sinne Projektweit) angesehen sonst...)

Gruß,
Dong