Für die Printausgabe in Floor mache ich folgendes:

ostream & operator<< (std::ostream &o,const Floor & c)
{
	c.Print();
	return o;
}

void Floor::Print() const
{

	cout << "blabla" << mBlabla;
}

print im Haus:

void House::Print() const
{
	copy(mFLoors.begin(),mFLoors.end(),ostream_iterator<Floor>(std::cout, " "));
}

Stöcke werden ins Haus so abgelegt:

void House::AddFloor(Floor const & flobj)
{
	mFLoors.push_back(flobj);
	mNrFloors++;
}

Eine Anomalie in deinem Code ist übrigens dein Operator <<. Der Sinn davon ist ja gerade, dass man in den allgemeinen ostream (bei dir o) schreibt, nicht nach cout.

also gut hier ist die basis aller basisklassen object

class Object
{
public:
	// destructor must me declared as virtual because if we delete from an
	// object pointer a derived class the destructor must be called from
	// that class
	virtual ~Object();
	virtual void Print() const;
protected:
	// hide all default CTors per default so no Object class can be created
	Object();
private:
	//hide also the Copy-Ctor
	Object (const Object & obj);
	//no assignment is allowed (also for inherit classes)
	Object& operator =( Object const & oSrc );
};

hier ist das header für das haus:

//forward declaration
class Floor;

class House: public Object
{
public:
	House();
	virtual ~House();
	virtual void Print() const;
//andere Funktionen
	void AddFloor(Floor const & flobj);

private:
	TAddress mAddress;
	TFloorList mFLoors;
	size_t mNrFloors;
};

ctor dtor (dotr noch nicht implementiert (also zurzeit leergelassen)

House::House():mNrFloors(0)
{
}

klassendefinition stöcke

class Floor: public Object
{
public:
	//paar Funktionen von der Aggregation einer weiteren Klasse die ich jetzt ausblende
	virtual void Print() const;
	Floor (const Floor & cFloor);  //wenn ich das nicht definiere kriege ich einen fehler, wieso das ohne dem nicht geht, habe ich noch nicht verstanden
	Floor();
	virtual ~Floor();

private:
	size_t mNrFlat;

};

aufruf im main:

Floor ws;
	ws.SetNrFlat(size_t(10));
	ws.GetNrFlat();
	House haus;
	haus.AddFloor(ws);

	haus.Print();
	//ws.Print(); das geht natürlich aber beim oberen bekomme ich den undefinierten zustand

	cout <<endl

ich hoffe soviel code reicht jetzt

Floor (const Floor & cFloor);  //wenn ich das nicht definiere kriege ich einen fehler, wieso das ohne dem nicht geht, habe ich noch nicht verstanden

Denn wenn du nicht weißt, wozu man einen Kopierkonstruktor brauchen kann, dann weißt du auch nicht, was man da reinschreibt. Insbesondere kopierst du dann nichts und verlierst scheinbar die "Werte vom Stock".

Starke Vermutung: Der Fehler steckt in diesem Kommentar:

Floor (const Floor & cFloor);  //wenn ich das nicht definiere kriege ich einen fehler, wieso das ohne dem nicht geht, habe ich noch nicht verstanden

Denn wenn du nicht weißt, wozu man einen Kopierkonstruktor brauchen kann, dann weißt du auch nicht, was man da reinschreibt. Insbesondere kopierst du dann nichts und verlierst scheinbar die "Werte vom Stock".

wozu einen kopierkonstruktor benutzen?:
um ein uninitialisiertes objekt mit einem schon initiliasierten objekt zu initiliasieren

aber wieso reicht bei meinem fall nicht der default copy-ctor?
denn wenn ich die schnittstelle für den copy-ctor wieder ausblende bekomme ich folgendes:

Error	1	error C2248: 'Object::Object' : cannot access private member declared in class 'Object'

habe es straightforward die eine Zeile im Stock-Copy-Ctor dazugeschrieben und es geht. Das was ich aber wirklich nicht weiß, ist:
wieso reicht der default copy-ctor nicht?

1. Bei der Fehlermeldung, die auftritt, wenn der Kopierkonstruktor von Floor nicht definiert ist, sagt dir der Compiler, an welcher Stelle er benötigt wird.
2. Du könntest dein Programm durchgehen und überlegen, wo wohl Objekte vom Typ Floor kopiert werden.
3. Du könntest im Kopierkonstruktor von Floor einen Breakpoint setzen.

Du hast folgende Möglichkeiten, das herauszufinden:

1. Bei der Fehlermeldung, die auftritt, wenn der Kopierkonstruktor von Floor nicht definiert ist, sagt dir der Compiler, an welcher Stelle er benötigt wird.
2. Du könntest dein Programm durchgehen und überlegen, wo wohl Objekte vom Typ Floor kopiert werden.
3. Du könntest im Kopierkonstruktor von Floor einen Breakpoint setzen.

1. fehler in der zeile 43 (ist jetzt nichtssagend, ohne irgendeine klasse im main zu benutzen) wo nur die zeichen }; stehen.
   2)hab jetzt genau den von dir vorhergesagten effekt gesehen
   3)siehe zwei

SeppJ schrieb:

Weil dein Floor ein Object ist und ein Object ist bei dir nicht kopierbar. Die Frage ist immer noch: Wozu ist die Object-Klasse eigentlich gut?

durch die eigene defintion des copy-ctors habe ich jetzt dieses effekt ausgehebelt?

also in der oop vorlesung haben wir gelernt, dass es gutes stil ist, wenn man von einer basis aller basisklassen (der nichts besonderes kann) andere klassen ableitet

also in der oop vorlesung haben wir gelernt, dass es gutes stil ist, wenn man von einer basis aller basisklassen (der nichts besonderes kann) andere klassen ableitet

1. Deine Basisklasse macht etwas. Nämlich verhindern, dass die entsprechenden Objekte kopiert werden können.
2. Wenn sie nichts besonderes können, wozu soll das dann gut sein?
3. Bist du wirklich sicher, dass du das richtig verstanden hast?

3. Bist du wirklich sicher, dass du das richtig verstanden hast?

GoF: program to an interface, not an implementation

Das Gesetz Nummer 1 in Java. Immer erst ein Interface schreiben mit den Methoden und dann eine Klasse, die es implementiert. Quasi die Java-Version von Header-Dateien (lol).

ACnut schrieb:

also in der oop vorlesung haben wir gelernt, dass es gutes stil ist, wenn man von einer basis aller basisklassen (der nichts besonderes kann) andere klassen ableitet

1. Deine Basisklasse macht etwas. Nämlich verhindern, dass die entsprechenden Objekte kopiert werden können.
2. Wenn sie nichts besonderes können, wozu soll das dann gut sein?
3. Bist du wirklich sicher, dass du das richtig verstanden hast?

1)also werden auch die default copy-ctoren der abgeleiteten klassen auch verhindert, ->sofern man diese selbst definiert (da bräuchte ich noch deine antwort)<-
2,3)hier haben wir eine ähnliche antwort wie der von java-checker gehört. ableitung von abstrakten klassen,uml-design...

bräuchte hier immer noch eine antwort:
durch die eigene defintion des copy-ctors für Floor ist diese sperre zumindest für floor deaktiviert oder?

[quote="java-checker"]

SeppJ schrieb:

Das Gesetz Nummer 1 in Java. Immer erst ein Interface schreiben mit den Methoden und dann eine Klasse, die es implementiert. Quasi die Java-Version von Header-Dateien (lol).

ja genau sowas ähnliches hat er bei uns auch gesagt( vielleicht auch nur, weil er auch java unterrichtet)

1)also werden auch die default copy-ctoren der abgeleiteten klassen auch verhindert, ->sofern man diese selbst definiert (da bräuchte ich noch deine antwort)<-

Nicht direkt, aber der compilergenerierte Copy-Ctor ruft automatisch den der Basisklasse auf, und das geht nicht, wenn der privat ist. Wenn du selbst einen definierst, und in der Initialisiererliste nicht den Basisklassen-Kopierkonstruktor aufrufst, dann nicht.

2,3)hier haben wir eine ähnliche antwort wie der von java-checker gehört. ableitung von abstrakten klassen,uml-design...

Das war ziemlich sicher Sarkasmus (und passt auch nicht ganz, Object ist ja kein Interface).

hmmm ok, danke

2,3)hier haben wir eine ähnliche antwort wie der von java-checker gehört. ableitung von abstrakten klassen,uml-design...

Das war ziemlich sicher Sarkasmus (und passt auch nicht ganz, Object ist ja kein Interface).[/quote]

also jetzt bin ich ziemlich verunsichert
ich glaub ich werde den lehrer nochmal fragen

danke für die hilfe

mfg
ACnut