ich habe folgende Code Struktur:

// Terrain.h
#include "Quadtree.h"

namespace A {

namespace B {

   class Terrain {
   private:
       QuadTree* quadtree;

       class SharedData {

       };
       SharedData* sharedData;
       friend class QuadTree;

   };
}

}

Und:

// Quadtree.h

namespace A {

namespace B {

   class Terrain::SharedData;  // Forward deklaraction

   class QuadTree {
   public:
      QuadTree(Terrain::SharedData* sharedData);

   };
}

}

Kurz zusammengefasst: Terrain hat einen Zeiger auf QuadTree und eine innere Klasse SharedData. Damit die Klasse QuadTree auf die Klasse Terrain::SharedData zugreifen kann, ist QuadTree friend von Terrain.
In Quadtree.h inkludiere ich jetzt NICHT Terrain.h, denn sonst gäbs ja eine endlose Headerrekursion. Da ich aber im QuadTree Ctor einen Zeiger auf Terrain::SharedData übergebe, mache ich eine Forward Declartion auf Terrain::SharedData.
Wenn ich jetzt Terrain.cpp kompiliere, kriege ich aber diesen Fehler in Quadtree.h (in der Zeile des Qudtree Ctor):

Error 2 error C2653: 'Terrain' : is not a class or namespace name quadtree.h

Ich verstehe nicht ganz wieso das nicht geht. Kann mir das wer sagen und wie ich den Fehler wegkriege?

Danke!

Den Fehler beseitigen kannst du, indem du genau anders herum forward deklarierst:
#include von Terrain.h in Quadtree.h und forward von Quadtree in Terrain.h.

Allerdings scheint mir das Design sehr zweifelhaft. Eine Klasse, die mit einem Pointer auf eine private Klasse einer anderen Klasse erzeugt werden muss, stinkt. Sehr! Ich würde an deiner Stelle lieber dieses Design gerade ziehen.

Stefan.

Nun ja... warum es nicht geht, sagt schon die Fehlermeldung: Terrain ist in Quadtree.h unbekannt.

Das versteh ich nicht. Natürlich ist Terrain nicht bekannt, deshalb benutz ich ja die Forward Declaration. Das ist doch der Sinn einer Forward Declaration? Ich sage dem Compiler: Jetzt kommt gleich ein Typ, für den kennst du noch keine Deklaration, aber das passt schon.
Ist meine Syntax falsch? Oder ist das Problem, dass SharedData eine innere Klasse ist?

DStefan schrieb:

Nun ja... warum es nicht geht, sagt schon die Fehlermeldung: Terrain ist in Quadtree.h unbekannt.

Das versteh ich nicht. Natürlich ist Terrain nicht bekannt, deshalb benutz ich ja die Forward Declaration. Das ist doch der Sinn einer Forward Declaration? Ich sage dem Compiler: Jetzt kommt gleich ein Typ, für den kennst du noch keine Deklaration, aber das passt schon.
Ist meine Syntax falsch? Oder ist das Problem, dass SharedData eine innere Klasse ist?

Letzteres. Terrain muss bekannt sein, damit du ein Element von Terrain forward deklarieren kannst. Einen Namespace würdest du hierzu einfach ein weiteres Mal öffnen, im Falle einer Klasse kannst du das Gewünschte gar nicht sagen.

Stefan.

Das heißt im Klartext, dass eine Vorwärtsdeklartion auf eine Innere Klasse immer UNMÖGLICH ist?

Ja, siehe http://www.c-plusplus.info/forum/viewtopic-var-t-is-234000.html

München schrieb:

Das heißt im Klartext, dass eine Vorwärtsdeklartion auf eine Innere Klasse immer UNMÖGLICH ist?

Ja, siehe http://www.c-plusplus.info/forum/viewtopic-var-t-is-234000.html

... und das ist doch auch konsequent! Du darfst etwas nicht verwenden, das nicht definiert ist. Und eine solche forward-Deklaration verwendet die äußere Klasse. Ich würde es schon ziemlich "unnatürlich" finden, wenn eine solche Deklaration akzeptiert würde.

Stefan.

... und das ist doch auch konsequent! Du darfst etwas nicht verwenden, das nicht definiert ist. Und eine solche forward-Deklaration verwendet die äußere Klasse. Ich würde es schon ziemlich "unnatürlich" finden, wenn eine solche Deklaration akzeptiert würde.

Ja, das ist der aktuelle Grund, wieso es nicht funktioniert, und macht so gesehen auch Sinn. Aber ganz konsequent finde ich es trotzdem nicht. Eine Vorwärtsdeklaration soll sagen, dass es einen Typen mit diesem Namen gibt - Nested hin oder her. Dass man die Klasse zusätzlich angibt, dient ja nur der Typsicherheit, deswegen muss die Klasse nicht zwingend bekannt sein (ok, im Status Quo schon, aber es wäre sicher kein Problem, für Vorwärtsdeklarationen von Nested Types diesbezüglich eine Ausnahme zu machen).

So, wie es momentan gelöst ist, wird man gezwungen, die innere Klasse aus der äusseren zu nehmen oder mit void* zu arbeiten und die Typsicherheit aufzugeben. Beides finde ich nicht unbedingt das Wahre.

Ähnliches sieht man ja zum Beispiel auch bei enum s, die momentan nicht vorwärtsdeklariert werden können. Hier soll sich der neue Standard ja auch ändern.

DStefan schrieb:

... und das ist doch auch konsequent! Du darfst etwas nicht verwenden, das nicht definiert ist. Und eine solche forward-Deklaration verwendet die äußere Klasse. Ich würde es schon ziemlich "unnatürlich" finden, wenn eine solche Deklaration akzeptiert würde.

Ja, das ist der aktuelle Grund, wieso es nicht funktioniert, und macht so gesehen auch Sinn. Aber ganz konsequent finde ich es trotzdem nicht. Eine Vorwärtsdeklaration soll sagen, dass es einen Typen mit diesem Namen gibt - Nested hin oder her. Dass man die Klasse zusätzlich angibt, dient ja nur der Typsicherheit, deswegen muss die Klasse nicht zwingend bekannt sein (ok, im Status Quo schon, aber es wäre sicher kein Problem, für Vorwärtsdeklarationen von Nested Types diesbezüglich eine Ausnahme zu machen).

So, wie es momentan gelöst ist, wird man gezwungen, die innere Klasse aus der äusseren zu nehmen oder mit void* zu arbeiten und die Typsicherheit aufzugeben. Beides finde ich nicht unbedingt das Wahre.

Ähnliches sieht man ja zum Beispiel auch bei enum s, die momentan nicht vorwärtsdeklariert werden können. Hier soll sich der neue Standard ja auch ändern.

Ich verstehe deine Argumentation. Und es ist ja nicht so, dass ich die Sprache "besudelt" fände, sollte eine solche Deklaration möglich sein. (Falls du verstehst, was ich meine ) Technisch ist eine solche Deklaration ganz Ok.

Meine Bedenken liegen eher auf der Bedeutungs-Ebene. Was bedeutet es (bei einem wohl ausgewogenen Design), wenn eine Klasse in einer anderen enthalten ist? Die innere Klasse ist ein Teil der Definition der äußeren, sie gehört ihr. Sie bedeutet nur etwas im Kontext der äußeren Klasse. Deshalb spreche ich von Konsequenz, wenn eine solche forward-Deklaration nicht möglich ist. Es würde mich einfach irritieren, solchen Code zu lesen. Etwas in der Art....

Was die forward-Deklaration von enums betrifft, sehe ich den Sinn nicht. Wofür würde man das benötigen? Hast du ein Beispiel?

Stefan.

Meine Bedenken liegen eher auf der Bedeutungs-Ebene. Was bedeutet es (bei einem wohl ausgewogenen Design), wenn eine Klasse in einer anderen enthalten ist? Die innere Klasse ist ein Teil der Definition der äußeren, sie gehört ihr. Sie bedeutet nur etwas im Kontext der äußeren Klasse. Deshalb spreche ich von Konsequenz, wenn eine solche forward-Deklaration nicht möglich ist. Es würde mich einfach irritieren, solchen Code zu lesen. Etwas in der Art....

Stimmt, da hast du völlig Recht. Meistens würde es auch eine freie Hilfsklasse tun.

Ich hatte bei mir ein public -Nested-Struct, das bestimmte Eigenschaften der äusseren Klasse zusammenfasste und als Ganzes herumgegeben werden konnte. Die einzige Instanz dieser inneren Klasse liegt in der äusseren. Mir schien hierbei die logische Bindung recht stark, sodass ich die Klasse innerhalb deklarierte. Aber Klassen, die im public -Bereich deklariert werden, sind sowieso ein bisschen speziell. Das ist schon einige Zeit her, heute würde ich wohl eher beide Klassen frei implementieren und gegebenenfalls in der einen (ursprünglich äusseren) ein typedef auf die andere einrichten. Mich hat es anfänglich halt ein wenig erstaunt, dass so eine Vorwärtsdeklaration nicht funktioniert. Aber inzwischen halte ich das nicht mehr für so schlimm...

DStefan schrieb:

Was die forward-Deklaration von enums betrifft, sehe ich den Sinn nicht. Wofür würde man das benötigen? Hast du ein Beispiel?

Es hat eigentlich den gleichen Sinn wie bei Klassen: Man möchte nicht den Header mit der Definition einbinden, weil man nicht auf den Typ zugreift, sondern nur weiss, dass es sich um einen bestimmten Typen handelt - letztendlich also zur Gewährung von Typsicherheit.

Hm, anstatt hier ein künstliches Beispiel zu konstruieren, kann ich dir gleich einen Anwendungsfall von mir zeigen (es geht um ein Spiel):

// ==== Item.hpp ==================================

enum ItemType
{
    // einige Gegenstandstypen
};

// Item-Klasse und weiteres...

// ==== Player.hpp ================================

#include "Item.hpp" // <- momentan erforderlich

class Player
{
    public:
        void CollectItem(ItemType NewItem);
};

Player besitzt hier kein Member des Typs ItemType , sondern führt beim Einsammeln je nach Gegenstand unterschiedliche Aktionen aus, die in CollectItem() geregelt sind. ItemType wird also nur für diese eine Funktion gebraucht. Hier würde eine Vorwärtsdeklaration reichen, dann müsste man den Header "Item.hpp" nicht einbinden (ansonsten braucht der Spieler nämlich nichts über Gegenstände zu wissen). Erst in der "Player.cpp" wäre "Item.hpp" dann inkludiert.

DStefan schrieb:

Was die forward-Deklaration von enums betrifft, sehe ich den Sinn nicht. Wofür würde man das benötigen? Hast du ein Beispiel?

Es hat eigentlich den gleichen Sinn wie bei Klassen: Man möchte nicht den Header mit der Definition einbinden, weil man nicht auf den Typ zugreift, sondern nur weiss, dass es sich um einen bestimmten Typen handelt - letztendlich also zur Gewährung von Typsicherheit.

Hm, anstatt hier ein künstliches Beispiel zu konstruieren, kann ich dir gleich einen Anwendungsfall von mir zeigen (es geht um ein Spiel):

// ==== Item.hpp ==================================

enum ItemType
{
    // einige Gegenstandstypen
};

// Item-Klasse und weiteres...

// ==== Player.hpp ================================

#include "Item.hpp" // <- momentan erforderlich

class Player
{
    public:
        void CollectItem(ItemType NewItem);
};

Player besitzt hier kein Member des Typs ItemType , sondern führt beim Einsammeln je nach Gegenstand unterschiedliche Aktionen aus, die in CollectItem() geregelt sind. ItemType wird also nur für diese eine Funktion gebraucht. Hier würde eine Vorwärtsdeklaration reichen, dann müsste man den Header "Item.hpp" nicht einbinden (ansonsten braucht der Spieler nämlich nichts über Gegenstände zu wissen). Erst in der "Player.cpp" wäre "Item.hpp" dann inkludiert.

Hmmm - ich verstehe. Das wäre dann der zweite Anwendungsfall von forward-Deklarationen, also die Vermeidung von Header-Abhängigkeiten. Ist ja in großen Projekten durchaus ein Punkt. Ich hatte bei meiner Frage nur an den ersten Anwendungsfall gedacht, dass also bestimmte Datenstrukturen einfach nicht formulierbar sind, wenn man nicht forward deklarieren kann.

Danke für das Beispiel.

Stefan.

Hmmm - ich verstehe. Das wäre dann der zweite Anwendungsfall von forward-Deklarationen, also die Vermeidung von Header-Abhängigkeiten. Ist ja in großen Projekten durchaus ein Punkt.

Ich setze Vorwärtsdeklarationen eigentlich meistens aus diesem Grund ein...

DStefan schrieb:

Ich hatte bei meiner Frage nur an den ersten Anwendungsfall gedacht, dass also bestimmte Datenstrukturen einfach nicht formulierbar sind, wenn man nicht forward deklarieren kann.

Jetzt bin ich mir nicht sicher, ob ich dich richtig verstanden habe. Meinst du, falls sich zwei Klassen gegenseitig benötigen (über Zeiger/Referenzen), dass du eine zuerst deklarieren musst?

DStefan schrieb:

Ich hatte bei meiner Frage nur an den ersten Anwendungsfall gedacht, dass also bestimmte Datenstrukturen einfach nicht formulierbar sind, wenn man nicht forward deklarieren kann.

Jetzt bin ich mir nicht sicher, ob ich dich richtig verstanden habe. Meinst du, falls sich zwei Klassen gegenseitig benötigen (über Zeiger/Referenzen), dass du eine zuerst deklarieren musst?

Genau das! Ich finde, diese Art der Verwendung ist das entscheidende Argument für die Nützlichkeit von forward-Deklarationen. Ohne diese bräuchte man sie nicht. Die Möglichkeit zur Verringerung von Header-Abhängigkeiten ist für mich nur ein Nebeneffekt (wenn auch ein durchaus nützlicher).

Stefan.