Ich habe eine kurze Frage zu C++ Regeln, da ich da momentan ein bisschen am Herumspielen bin.
Wenn ich beispielsweise zwei Klassen habe und jede dieser zwei Klassen in einer Headerdatei steht so muss ich um beide Klassen zu instanziiren beide Header in die CPP Datei einbinden.

Wenn ich eine der beiden Klassen nun innerhalb der anderen verwenden will, so muss ich den Header der einen Klasse in die h-Datei der anderen einbinden und umgekehrt.
Was jedoch tue ich, und was ist erlaubt, wenn ich:

Die eine Klasse innerhalb der anderen verwenden will und die andere innerhalb der einen?
Den Header ein zu binden funktioniert noch.

Doch sobald ich auch nur einen Zeiger auf das andere Element erstelle stuertzt der Compiler ab und erkennt die Namen nicht mehr.

Gibt es Moeglichkeiten dies zu umgehen?

Ich habe gehoert, dass man mit Vorwaertzdeclaration das ganze loesen kann, aber auch das funktioniert bei mir nicht.
Ich kann dann zwar in der einen Klasse, die andere declarieren und sogar einen Zeiger auf sie uebergeben, aber mit diesem Zeiger darf ich ja nichts tun.
Ich darf beispielsweise keinen Speicher fuer ihn reservieren oder ein Objekt aus ihm erstellen, denn er ist schliesslich in der zweiten Klasse erst declariert, aber nicht definiert.

Zum Beispiel das hier:

Test1.h:

#include <B.h>
class B;
class A
{
   A(B * b)
   {
      b = malloc... //ES KNALLT!
   }
};

Test2.h:

#include <A.h>
class A;
class B
{
   B(A *a)
   {
      a = new A; //ES KNALLT EBENFALLS!
   }
}

Wo ist mein Ansatz falsch?

Tschuess

David

Wo ist mein Ansatz falsch?

Dein Ansatz ist vollkommen richtig, nur der Schluss hängt Du musst einfach zu jeder Klasse eine .cpp-Datei machen, in die dann die Implementation kommt, also etwa so:

// A.h
class B;

class A
{
   A( B * b );           // <- Deklaration
   B* func( int blubb ); // <- Deklaration
};

// B.h
class A;

class B
{
   B(A *a); // - Deklaration
}

// A.cpp
#include "A.h"
#include "B.h"

A::A( B* b )
{
    // Der Konstruktor-Code..
}

B* A::func( int blubb )
{
    // ....
}

// B.cpp
#include "B.h"
#include "A.h"

B::B( A* a )
{
    // Der Konstruktor-Code..
}

Test1.h:

#include <B.h>
class B;
class A
{
   A(B * b)
   {
      b = malloc... //ES KNALLT!
   }
};

Et knallt gleich vorm Bildschirm, wenn hier noch mal wer malloc in C++ benutzt!

Wieso darf ich malloc nicht in C++ benutzen? Habs schon oefter mal benutzt...

Weil es nicht das gleiche, wie new ist. malloc funktioniert solange, wie du mit POD's arbeitest, aber sobald du eine Klasse mit einem eigenen ctor hast, wird der von malloc nicht aufgerufen. malloc benutzen solltest du nur, wenn du ganz sicher bist, was du machst und warum du ihn brauchst.

Wieso darf ich malloc nicht in C++ benutzen? Habs schon oefter mal benutzt...

Noch ergänzend zu drakon Post, da ich die Freigabe nicht sehe:
Zusätzlich IMMER die Allozierung/Freigabe mit dem Gegenstück machen (new/delete, new[]/delete[], malloc/free), NIEMALS mischen!

Ein komplett lauffaehiges Anwendungsbeispiel ist hier zu finden:

http://www.david777.de/htdocs/doku.php?id=wiki:own_faq

Und nur zur Info, mit malloc alloziierter Speicher ist der Heap, mit new ist es der Free Store und die sind nicht gleich.

Könnte es sein, das du hier ein wenig Sprachen/Frameworks durcheinander bringst? Wäre mir neu das man unter C++ mittels new nichts auf dem Heap erstellt (u.a. weil häufig intern eine Umsetzung mittels malloc erfolgt)

cu André

Gab es vorher den Fehler weil gegenseitiges inkludieren nicht erlaubt ist?

gegenseitig inkludieren ist ok, nur du musst auch die klassenschnittstelle deklarieren

class B;

sagt dem compiler "es gibt eine klasse mit namen B"
damit kann man schon einen zeiger bilden, aber noch kein objekt, weil der compiler
nicht weiß, was für daten drin stehen oder ob du virtuelle funktionen benutzt.

class B
{
//....
};

macht dem compiler die schnittstelle bekannt, damit kannst du schon objekte
anlegen und funktionen aufrufen
das ganze lässt sich dann auch kompilieren, nur nicht linken.

für das linken braucht man dann noch die definition.

777 schrieb:

Ich wusste garnicht, dass es ueberhaupt moeglich ist das zu mischen.

du kannst alles mischen nur geht es bestimmt schief.

fstream file("dat.txt");
delete &file;

syntaxmäßig ist es korrekt, ich kann es auch kompilieren

Ich wusste bisher nur von 'Stack' und 'Heap' und bin davon ausgegangen, dass alles was mit new freigegeben wird auf dem grossen 'Heap' landet und alles ohne new auf dem kleineren 'Stack'.

Der Stack wird nur bei nicht-dynmaischen Variablen verwendet. new/delete erzeugen daher nie etwas auf dem Stack (Auch wenn der Zeiger auf den Speicherbereich dort liegen kann).

777 schrieb:

Und new benutzt dann also auch nur malloc?

Bitte lies vollständig. Nein, new kann - muß aber nicht - intern malloc verwenden, ruft aber zusätzlich Konstruktoren auf etc. (ebenso wie delete im Gegensatz zu free Destruktoren aufruft).

Merk dir einfach: Unter C++ new/delete verwenden.
Die Ausnahmefälle in denen man dies nicht tut sind verschwindend gering (z.B. bei eigenen Speicherverwaltungen wäre es möglich das man dies anders löst)

cu André

Siehe "Exceptional C++" http://www.gotw.ca/publications/xc++.htm

Würdest du bitte etwas genauer werden (Vielleicht wenigstens mit Angabe der Kapitelnummer, noch besser wäre aber eine Kurzzusammenfassung in ein oder zwei Sätzen)? Und wäre es zuviel verlangt wenigstens ein klein wenig zu zitieren, damit alle verstehen auf was du dich beziehst.

Aber hier ist google mein freund, einmal kurz hier: http://books.google.de/books?id=58rZvOSuheEC&pg=PA143&lpg=PA143&dq=exceptional+c%2B%2B+free+store&source=bl&ots=LZLkissXLl&sig=LFAx17G40J2xR-JqI5MWTKk5Mxs&hl=de&sa=X&oi=book_result&resnum=1&ct=result

Die eigentliche Seite ist nicht indiziert

Aber yay, da ist die Liste http://my.safaribooksonline.com/0201615622/ch35lev1sec1?portal=oreilly , welche nur zufällig angezeigt wird, aaaaaw.

Naja hier ist mein Cache

Table 1. C++'s Memory Areas
Memory Area Characteristics and Object Lifetimes
Const Data The const data area stores string literals and other data whose values are known at compile-time. No objects of class type can exist in this area.
All data in this area is available during the entire lifetime of the program. Further, all this data is read-only, and the results of trying to modify it are undefined. This is in part because even the underlying storage format is subject to arbitrary optimization by the implementation. For example, a particular compiler may choose to store string literals in overlapping objects as an optional optimization.

Stack The stack stores automatic variables. Objects are constructed immediately at the point of definition and destroyed immediately at the end of the same scope, so there is no opportunity for programmers to directly manipulate allocated but uninitialized stack space (barring willful tampering using explicit destructors and placement new).
Stack memory allocation is typically much faster than for dynamic storage (heap or free store) because each stack memory allocation involves only a stack pointer increment rather than more-complex management.

Free Store The free store is one of the two dynamic memory areas allocated/freed by new/delete.
Object lifetime can be less than the time the storage is allocated. That is, free store objects can have memory allocated, without being immediately initialized, and they can be destroyed, without the memory being immediately deallocated. During the period when the storage is allocated but outside the object's lifetime, the storage may be accessed and manipulated through a void*, but none of the proto-object's nonstatic members or member functions may be accessed, have their addresses taken, or be otherwise manipulated.

Heap The heap is the other dynamic memory area allocated/freed by malloc()/free() and their variants.
Note that while the default global operators new and delete might be implemented in terms of malloc() and free() by a particular compiler, the heap is not the same as free store, and memory allocated in one area cannot be safely deallocated in the other.

Memory allocated from the heap can be used for objects of class type by placement new construction and explicit destruction. If so used, the notes about free store object lifetime apply similarly here.

Global/Static Global or static variables and objects have their storage allocated at program startup, but may not be initialized until after the program has begun executing. For instance, a static variable in a function is initialized only the first time program execution passes through its definition.
The order of initialization of global variables across translation units is not defined, and special care is needed to manage dependencies between global objects (including class statics). As always, uninitialized proto-objects' storage may be accessed and manipulated through a void*, but no nonstatic members or member functions may be used or referenced outside the object's actual lifetime.

Bitte