struct global machen

F98

Ich würde mal sagen:

Das Struct in eine *.h packen:

#ifndef LustigeHeaderdateiH
#define LustigeHeaderdateiH

struct my_settings
{ 
   AnsiString Filename; 
   AnsiString ClientName; 
   AnsiString AppName; 
   AnsiString Homepage; 
   AnsiString Config_link; 
   AnsiString Patch_List; 
   AnsiString Dyndns; 
   bool IpResolve; 
   AnsiString Play; 
} Inet_Config;

#endif

Und diese *.h in alle *.cpps oder *hs (wo Du sie halt brauchst) einbinden.

Geo

So nun gerade nicht, da dann jedes Modul eine eigene Kopie der Struktur benutzt!

#ifndef LustigeHeaderdateiH 
#define LustigeHeaderdateiH 

struct my_settings 
{  
   AnsiString Filename;  
   AnsiString ClientName;  
   AnsiString AppName;  
   AnsiString Homepage;  
   AnsiString Config_link;  
   AnsiString Patch_List;  
   AnsiString Dyndns;  
   bool IpResolve;  
   AnsiString Play;  
};

extern struct my_settings Inet_Config;
#endif

und in _einem_ .cpp File außerhalb der Funktionen

struct my_settings Inet_Config;

Dreamgazer

Scheint zu funktionieren danke ... naja ich werde mal noch genauer testen glaube das kann man so mit klassen auch machen

F98

Dann gib doch von Unit1 einen Zeiger von dem erstellten Objekt an Unit2 und Unit3. :p

dschensky

Geo,

Geo schrieb:

#ifndef LustigeHeaderdateiH 
#define LustigeHeaderdateiH 
 
struct my_settings 
{  
...
};
 
extern struct my_settings Inet_Config;
#endif

so würde ich es nun auch wieder nicht machen. Du greifst in der Schnittstellen-Datei (.h) auf die Variable "Inet_Config" zu, bist also zwingend davon abhängig, daß diese Variable irgendwo anders auch tatsächlich definiert wurde. Die Verwendung eines Typs währe somit zwingend an die Existenz einer konkreten Variable gebunden. Der CBuilder macht das zwar so mit jedem Formular. Das geht aber in Ordnung, weil die Formular-.h-Datei stets mit der zugehörigen Formular-.cpp-Datei daherkommt, wo die Formular-Variable auch definiert ist (ganz oben - z.B.: "TMyForm *MyForm");

Also:

in die .h-Datei nur die Deklaration des Typs
eine Variable dieses Typs irgendwo(anders) definieren - z.B. in einer "globals.h"
dort, wo die Variable gebraucht wird, die extern-Anweisung einfügen (und gegebenenfalls die "globals.h" inkludieren)

chris_f schrieb:

Auf die Gefahr hin, das ich gleich Schläge bekomme, von wegen Daten kapseln und private und so...

Prinzipiell gelten globale Variablen natürlich als unschön, was aber nicht bedeutet, daß
a) sie nicht trotzdem wahnsinnig praktisch sein können und
b) ich ernsthaft behaupten könnte, sie nie zu benutzen

Dreamgazer

Nah das was Geo geschrieben hat läuft nun so wie es soll

Mal gleich ne andere frage hinterhier: Online status soll in allen modulen sichtbar sein (multitheading) wird auch geändert. Wie soll man sowas ohne globale daten machen? Was ich damit sagen will jede app braucht globale strukturen um zu wissen was vorsich geht. Da fällt mir gerade ein man kann auch einiges über message ports erledigen aber soweit bin ich noch nicht ...

PS: Global oder nicht das eher glaubensfrage. Man sollte sie vermeiden aber auch benutzen wo sie sinnvoll sind und im meinem fall sollte man es tun. Ganz bessonders da sie nie mehr geändert werden nur beim init halt

Geo

@dschensky

so würde ich es nun auch wieder nicht machen.

Du hast recht, das ist nicht schön, war aber auch nicht die Frage.
Dreamgazer fragte nach der Realisierung für eine häßliche verabscheungswürdige globale Struktur.

Du greifst in der Schnittstellen-Datei (.h) auf die Variable "Inet_Config" zu

Nein.

bist also zwingend davon abhängig, daß diese Variable irgendwo anders auch tatsächlich definiert wurde.

Ja natürlich (sonst meckert der Linker das schon).

Dreamgazer

@Geo

so so verabscheungswürdig? :p wie würdest du es machen? das prob kennst du ja schon. Na dann los

dschensky

Geo,

Geo schrieb:

Dreamgazer fragte nach der Realisierung für eine häßliche verabscheungswürdige globale Struktur.

Dreamgazer fragte nach einer globalen Struktur.
"häßlich" und "verabscheuungswürdig" sind Deine Wortschöpfungen.

Geo schrieb:

Du greifst in der Schnittstellen-Datei (.h) auf die Variable "Inet_Config" zu

Nein.

Mit "Zugriff" meinte ich nicht die direkte Verwendung der Variablen, obwohl der Zwang, die Variable irgendwo definieren zu müssen, indirekt auch einen Zugriff in Deinem Sinne darstellt.

DerAltenburger

Also ich wuerde das ganz anders machen ...

in einer eigenen Unit:

**********Header- Datei Anfang*********
class T4All:public TPersistent
{
  static int Counter;
  static int CountTotal;
  int Num;
  .
  .//Constructor(en)
   //Destructor
  .
}
T4All::Counter=0;
T4All::CountTotal=0;
**********Header- Datei Ende*********

*********CPP- Datei Anfang*************

im Constructor:
  .
  .
  .
  Counter++;
  CountTotal++;
  Num=CountTotal;
  .
  .
  .

im Destruktor:
  .
  .
  .
  Counter--;
  .
  .
  .

*********CPP- Datei Ende*************

Die Membervariablen in der Klasse sind Applicationsweit einmalig, egal wie viele Instanzen ich von der Klasse erzeuge!
=> Jede Instanz kennt die Anzahl der Instanzen, Anzahl total erzeugter
Instanzen und eigene Nummer.

Der Zugrif auf Counter, CountTotal ist auch moeglich ohne eine instanz zu erzeugen.

In jedem Modul, wo die Daten gebraucht werden, kann eine (eigene) Instanz erzeugt werden. All Instanzen nutzen fuer die Static- Variablen den gleichen Speicherplatz!

PS:
Wenn anstelle der 'sinnlosen Counter' 'ne brauchbare Datensatz- Struktur benutzt wird, koennte das Ganze recht hilfreich sein!