Strukturen vs. Klassen?!

Hallo,

mal ne einfache theoretische Praxisfrage
Also in meinem Buch wurden zuerst Strukturen erklärt, die ja auch etwas einfacherer als Klassen sind. Aber ich frage mich gerade, wozu man überhaupt noch Strukturen nutzen sollte wenn man Klassen hat. Eigentlich nur wenn man Klassen nicht versteht oder? *g*
Ne, mal im Ernst. Ist doch fast das gleiche nur das Klassen noch viel besser genutzt werden können. Und in einem richtigen Spiel udgl. wird man doch immer jeweilige Memberfunktionen brauchen was Strukturen überfällig macht. Stimmt das so? Oder gibt es doch Grüne für reine Strukturen?

Wieso sollte man immer Memberfunktionen brauchen?
Manchmal braucht man Strukturen einfach nur dazu, Daten strukturiert zu speichern ohne dass man einen Konstruktor brauchte oder die Member explizit als public angeben zu wollen.

pmw

Hallo DarkRage,

Klassen und Strukturen sind gleichmächtig. D. h. du kannst mit beiden genau das gleiche machen. Es gibt nur einen unterschied. Wenn du Variablen in einer Klasse definierst, ohne "public" oder "private" davor zuschreiben, dann werden die bei Strukturen als "public" behandelt und bei Klassen als "private".

Beispiel:

struct Klasse1
{
   int i; // i ist public
}

class Klasse2
{
   int i; // i ist private
}

Ich hoffe, dass bringt dich weiter.

Viele Grüße
pmw

DarkRage

Mhh...

aber ich überlege die ganze Zeit.. ich finde einfach kein Beispiel für eine Struktur in einem Spiel. Eigentlich muss in einem Spiel ja alles verwaltet werden. Selbst ein Grashalm bräuchte eine Funktion die man in einer Klasse unterbringen könnte.

PS: Danke das du soviele Antworten bringst SeppSchrot

PS2 @ PMW
Gleichmächtig? Über Klassen sind doch Funktionen wunderbar integrierbar, was man von Strukturen nicht behaupten kann oder ?!

@PS1: Lol, kein Problem Rage

@PS2: Dadurch dass Structuren in C++ Sonderfälle von Klassen sind, kannst du sogar Funktionen in Structs packen. Sogar Konstrutoren.

struct mystruc
{
  int i;
  void machwas(int j) {i = j;}
};

FireFlow

struct und class sind wie gesagt gleich mächtig. Der einzige unterschied ist eben dass man bei einem struct als Standardsichtbarkeit public hat, und bei class private.

Gruß

DarkRage

Mh das is verdammt interessant, dass kommt im Buch nämlich gar nicht so rüber.

Danke

linu*x*bie

Also Strukturen eignen sich perfekt für kleine Gruppierungen oder sogar neue Datentypen. Ein Beispiel für eine Struktur, die man häufig in einem Spiel auffindet:

typedef struct pos_{
    int x;
    int y;
    int z;
} pos;

Nun kannst Du das ganze variabel in Deine Klassen einbetten:

class Cfigure3D
{
     private:
          // ... unzahlige andere Eigenschaften
          pos fig_pos;
          // ...
     public:
          // ... unzaehlige andere methoden
          pos SetPos(int x, int y, int z);
};

Da andere figuren/dinge zb eine andere Validirung der Koordinaten brauchen ist es sinlos sich in einer classe CPos gleich auf irgendwelchen Set-Methoden festzuklamern.

mfg

volkard

linu(x)bie schrieb:

Also Strukturen eignen sich perfekt für kleine Gruppierungen oder sogar neue Datentypen. Ein Beispiel für eine Struktur, die man häufig in einem Spiel auffindet:
typedef struct pos_{
    int x;
    int y;
    int z;
} pos;

ja, in c.

in c++ schreibt man besser

struct Pos{
    int x;
    int y;
    int z;
};

und dann baut man einen konstruktor. dann noch schnell ne abs-funktion, und ganz wichtig nen operator-, um abstände zu ermitteln. dann gleich += + -= - += und * mit skalaren. wirst kaum drumherumkommen.

generell nimmt man struct, wenn es so platte typen wie Pos sind. ein paar methoden und konstruktoren stären dabei überhaupt nicht. außerdem nimmt man struct fast immer für listen-knoten und baum-knoten, die vollständig privat innerhalb der umgebenden klasse leben und keinen schutz brauchen.
statt class nur struct zu schreiben ist ein kommentar für den leser und sagt eigentlich nur "dieser datentyp ist nicht spannend, hier passiert nix weltbewegendes".

groovemaster

@DarkRage
struct verwendet man ganz gerne für PODs. Sowas können zB relativ simple Datencontainer sein, wie die von volkard angesprochenen nested Klassen. Oder auch Klassen, die in Verbindung mit dem Strategy Pattern bzw. Policies zum Einsatz kommen. Grundsätzlich ist das aber vollkommen egal, da struct letztendlich, bis auf die bereits angesprochenen default Sichtbarkeit, exakt das gleiche wie class ist. AFAIK wurde struct nur aus Kompatibilität zu C beibehalten.