ich arbeite seit kurzer Zeit wieder mit C++. Mein Ziel ist es, dass 2 Klassen auf einander zugreifen können und auch ihre Methoden usw benutzen können.
Dateien :
A.h:

#pragma once // Include-Guard
#include "B.h"
class A
{
public:
	B b;
	A(void);
	~A(void);
};

A.cpp

#include "StdAfx.h"
#include "A.h"

A::A(void)
{
}

A::~A(void)
{
}

B.h

#pragma once
#include "A.h"
class B
{
public:
	B(void);
	~B(void);
	void greet();
};

B.cpp

#include "StdAfx.h"
#include "B.h"
using namespace std;

B::B(void)
{
}

B::~B(void)
{
}

void B::greet(){
	cout << "B says hello";
}

Example.cpp

#include "stdafx.h"
#include "A.h"
#include <string>
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
	A a;
	a.b.greet();
	string v;
	cin >> v;
	return 0;
}

Wie man deutlich sehen kann, verusuchen die Klassen A und B auf einander zu zugreifen und um das möglich zu machen müssen sie sich gegenseitig includieren. Es sollte eigentlich alles funktionieren, da #pragma once als Include-Guard dient. Wenn ich nun versuche in der A.h ein Objekt von B zu erstellen mekert der Compiler :

1>d:\jona\dokumente\visual studio 2010\projects\example\example\a.h(6): error C2146: Syntaxfehler: Fehlendes ';' vor Bezeichner 'b'
1>d:\jona\dokumente\visual studio 2010\projects\example\example\a.h(6): error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt.
1>d:\jona\dokumente\visual studio 2010\projects\example\example\a.h(6): error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt.

Wenn ich es aber so drehe, dass Klasse A und B sich nicht gegenseitig brauchen, dann funktioniert alles wunderbar. Also : Wie löse ich das Problem? Ich hoffe man kann mir helfen

Mit freundlichen Grüßen,

Jona

B.h

#pragma once
#include "A.h"//wozu??? das ist un-sparsames ruminkludieren. erst die B.cpp 
//inludiert B.h und A.h
class B
{
public:
	B(void);
	~B(void);
	void greet();
};

Nur wer unsparsam ruminkludiert, kann C++ nicht auf einem Laptop benutzen.

Wie man deutlich sehen kann, verusuchen die Klassen A und B auf einander zu zugreifen und um das möglich zu machen müssen sie sich gegenseitig includieren.

Nein, das sehe ich überhaupt nicht. B macht doch gar nichts mit A, außer dass in b.h sinnlos a.h inkludiert wird, was zu einer zirkularen Abhängigkeit führt. Selbst wenn in der b.cpp vielleicht irgendwann mal ein A-Objekt auftaucht, dann reicht es auch, wenn dort a.h eingebunden wird, anstatt in b.h. Falls in b.h eine Referenz oder Zeiger auf a.h benötigt wird, dann reicht auch eine Forward-declaration der Klasse A.

Es sollte eigentlich alles funktionieren, da #pragma once als Include-Guard dient.

Includeguards schützen nicht vor echten Fehlern, wie in diesem Fall einer zyklischen Abhängigkeit.

Noch ein paar Bemerkungen:
-void als Argument: Sind wir hier in C?
-Leerer Konstruktor/Destruktor: Da hat dir wohl irgendein stümperhaftes Lehrbuch beigebracht, dass man immer einen Konstruktor/Destruktor bräuchte. Unsinn.

#pragma once // Include-Guard
#include "B.h"
class A
{
public:
	B b;//ok, A braucht b! Das include ist nötig. 
	A(void);
	~A(void);
};

B.h

#pragma once
#include "A.h"//wozu??? das ist un-sparsames ruminkludieren. erst die B.cpp 
//inludiert B.h und A.h
class B
{
public:
	B(void);
	~B(void);
	void greet();
};

Nur wer unsparsam ruminkludiert, kann C++ nicht auf einem Laptop benutzen.

Ja das ist mir auch aufgefallen.. Das sind nur beispiel Klassen. Stell dir einfach vor beide brauchen sich.. Wie realisiere ich das?

Nein, das sehe ich überhaupt nicht. B macht doch gar nichts mit A, außer dass in b.h sinnlos a.h inkludiert wird, was zu einer zirkularen Abhängigkeit führt. Selbst wenn in der b.cpp vielleicht irgendwann mal ein A-Objekt auftaucht, dann reicht es auch, wenn dort a.h eingebunden wird, anstatt in b.h. Falls in b.h eine Referenz oder Zeiger auf a.h benötigt wird, dann reicht auch eine Forward-declaration der Klasse A.

Ja mein Fehler. Das sind nur Beispiel-Klassen. Ich frage mich jetzt, wie ich eine Forward-declaration anstelle?

[qoute="SeppJ"]
Noch ein paar Bemerkungen:
-void als Argument: Sind wir hier in C?
-Leerer Konstruktor/Destruktor: Da hat dir wohl irgendein stümperhaftes Lehrbuch beigebracht, dass man immer einen Konstruktor/Destruktor bräuchte. Unsinn.
[/qoute]

Was sollte ich statt void nehmen? Ich brauche in diese Funktion ja kein Return.
Und zu den Konstruktor/Dekonstruktor musst du dich bei Visual Studio beschweren. Trotzdem erstmal danke. Schadet es wenn ich konstruktoren habe, die ich nicht benutze?

B.h

#pragma once
//#include "A.h"//geht nicht! Zyklisch. 

class A;
//Liebes Visual Studio, 
//bitte weine nicht, wenn Du eine Verwendung von A als Klasse siehst, 
//obwohl Dir die ganzen Details von A noch nicht bekannt sind. 
//Ich verspreche Dir, daß ich Die bald alles verrate. 
//Beste Grüße, Volkard. 

class B
{
	A* pa;//8 Bytes, wie jeder Zeiger (64-bittig gedacht). Geht. 
public:
	A bar();//klappt sogar angeblich auch, hab ich aber nie verwendet. 
        void baz(A a);//dito
};

//Und die folgende Zeile habe ich in meinem unterirdischen Labor ertüftelt. 

//Volkards spätes include. 
#include "A.h"
//Dadurch ist die B wieder selfcontained.

Was sollte ich statt void nehmen? Ich brauche in diese Funktion ja kein Return.

void f(void)
wird zu
void f()

Jona192 schrieb:

Und zu den Konstruktor/Dekonstruktor musst du dich bei Visual Studio beschweren. Trotzdem erstmal danke.

Liebes Visual Studio,
bitte ärgere Jona192 nicht mehr so viel.
Beste Grüße, Volkard

Jona192 schrieb:

Schadet es wenn ich konstruktoren habe, die ich nicht benutze?

Ja, SeppJs Gemütsverfassung ändert sich, weils in seinen Augen so brennt. Sonst kein Schaden. Der Compiler erstellt sogar selber leere Konstruktoren, wenn Du es nicht machst. Aber seine sind inline (also innerhalb der Klasse definiert, wie meiner), dadurch kann selbst der dümmste Compiler den dann wieder wegoptimieren. Außerdem gehört es sich, kleine Trivialfunktionen im Header zu definieren, wenn die Definition zu lesen viel viel einfacher ist, als dazugehörige Kommentare/Dokumentation zu finden und zu lesen, die die Funktion umschreiben.

#pragma once // Include-Guard

#include "B.h"//Ja, ist nötig. 

class A
{
public:
	B b;//ok, A braucht b für size-Bestimmung natürlich! Das include ist nötig. 
	A(){
		b->foo();//auch dafür, aber man könntes ja auch in die A.cpp 
//verschiebten. 
        }
};

B.h

#pragma once
//#include "A.h"//geht nicht! Zyklisch. 

class A;
//Liebes Visual Studio, 
//bitte weine nicht, wenn Du eine Verwendung von A als Klasse siehst, 
//obwohl Dir die ganzen Details von A noch nicht bekannt sind. 
//Ich verspreche Dir, daß ich Die bald alles verrate. 
//Beste Grüße, Volkard. 

class B
{
	A* pa;//8 Bytes, wie jeder Zeiger (64-bittig gedacht). Geht. 
public:
	A bar();//klappt sogar angeblich auch, hab ich aber nie verwendet. 
        void baz(A a);//dito
};

//Und die folgende Zeile habe ich in meinem unterirdischen Labor ertüftelt. 

//Volkards spätes include. 
#include "A.h"
//Dadurch ist die B wieder selfcontained.

Hallo Volkard.

Erstmal Wow. Sehr sehr sehr vielen Dank, für diese sehr amüsante und unterhaltende erklärung. Ich musste echt des öfteren schmunzeln :D. Ich gehe jetzt mal davon aus, dass zeilen,wie

A(){
		b->foo();//auch dafür, aber man könntes ja auch in die A.cpp 
//verschiebten. 
        }

A* pa;//8 Bytes, wie jeder Zeiger (64-bittig gedacht). Geht.

A bar();

void baz(A a);//dito

nicht relevant sind, da es bei mir auch ohne diese Zeilen funktioniert hat. ich würde trotzdem gerne mal wissen, wozu eine Funktion wie foo() gedacht ist, da ich sie in mehreren code beispielen gesehen habe. Ich habe nur etwas von eine Platzhalter funktion gelesen. Außerdem würde ich auch noch gerne wissen, weshalb es dann funktioniert wenn ich das include von a.h gaaanz unten hin setzte, statt ganz an den anfang. Ich gehe davon aus, dass es die forward declaration stört, richtig?. Trotzdem sehr, sehr vielen Dank für deine Hilfe. Sehr Unterhaltend

Mit freundlichen Grüßen,

Jona

Jona192 schrieb:

Was sollte ich statt void nehmen? Ich brauche in diese Funktion ja kein Return.

void f(void)
wird zu
void f()

Gut da darf ich mich mal wieder die Schuld VS zuschieben. Ich dachte es wäre auf void greet(); bezogen.

volkard schrieb:

Jona192 schrieb:

Schadet es wenn ich konstruktoren habe, die ich nicht benutze?

Ja, SeppJs Gemütsverfassung ändert sich, weils in seinen Augen so brennt. Sonst kein Schaden. Der Compiler erstellt sogar selber leere Konstruktoren, wenn Du es nicht machst. Aber seine sind inline (also innerhalb der Klasse definiert, wie meiner), dadurch kann selbst der dümmste Compiler den dann wieder wegoptimieren. Außerdem gehört es sich, kleine Trivialfunktionen im Header zu definieren, wenn die Definition zu lesen viel viel einfacher ist, als dazugehörige Kommentare/Dokumentation zu finden und zu lesen, die die Funktion umschreiben.

Gut gut war ja auch nur eine Beispiel Klasse Werde ich mir mal für die Zukunft merken. Es gehört sich ja einen sauberen style zu haben.

Gruß,

Jona

ich würde trotzdem gerne mal wissen, wozu eine Funktion wie foo() gedacht ist, da ich sie in mehreren code beispielen gesehen habe. Ich habe nur etwas von eine Platzhalter funktion gelesen.

Jo. Es ist egal, wie die Funktion heißt oder was sie macht. Mir ging es nur darum, daß eine Forward-Deklariation dem Compiler nicht genug Detals erzählt, daß er Methoden von B schon kennen würde unbd aufrufen könnte.

b->foo();//auch dafür, aber man könntes ja auch in die A.cpp
//verschiebten.

b->f();//auch dafür, aber man könntes ja auch in die A.cpp
//verschiebten.

b->dingsda();//auch dafür, aber man könntes ja auch in die A.cpp
//verschiebten.

b->irgendeineFunktion();//auch dafür, aber man könntes ja auch in die A.cpp
//verschiebten.

Siehe auch http://de.wikipedia.org/wiki/Metasyntaktische_Variable

Jona192 schrieb:

Außerdem würde ich auch noch gerne wissen, weshalb es dann funktioniert wenn ich das include von a.h gaaanz unten hin setzte, statt ganz an den anfang.

Die meisten lassen es sogar im Header ganz weg! In der B.cpp müdden dann eben B.hpp UND A.hpp inkludiert werden.

Man darf es auch unten hinschreiben mit dem Zweck, daß man in der B.cpp nur noch die B.hpp zu inkludieren braucht und die A.hpp nicht mehr. Hauptsache, es steht nicht oben, denn oben würden sich die beiden Klassen zyklisch gegenseitig brauchen. So braucht die B nur einen Schatten von A, der gerade mal reicht, damit man Zeiger auf A und Funktionsargumente und Funktionsrückgaben per A machen kann und sonst nix. Sobald man mehr machen will wie ein echtes A anlegen oder von einem a eine Funktion aufrufen oder Attribute anschauen, dann ist der Schatten nicht genug (und dann gehts eben einfach nicht).