Namespace wird nicht gefunden
-
Nein, ich hab die Forward-Declaration ohne Namespace gemacht, jetzt funktioniert es prima. Und ja es ist doch kein Object sondern ein Zeiger. Danke für die Hilfe.
MfG SWW13
-
SWW13 schrieb:
//Lib.h #include "Core\Core.h" #include "D3D\D3D.h"---
//Core\Core.h #include "..\Lib.h" #include "Mouse.h" //Klasse Mouse ist in namespace Lib::Core #include ...---
//D3D\D3D.h #include "..\Lib.h" #include "GUI\GUI.h" //D3D\GUI\GUI.h//D3D\GUI\GUI.h #include "..\D3D.h" #include "Menu.h" //D3D\GUI\Menu.h #inlcude ...//D3D\GUI\Menu.h #include "GUI.h" using namespace Lib::Core; //<-Error: Core kein Element von Lib + Core keine Namespace namespace Lib { namespace D3D { namespace GUI { ...Äh... deine Header includen sich gegenseitig kreuz und quer, vielleicht solltest du mal ein bisschen Ordnung da rein bringen?
-
So, hab jetzt auch meine Includes aufgeräumt und nur die benötigeten Klassen direkt included. Allerdings bin ich auf ein neues Problem gestoßen:
Hab die Klasse Lib::D3D:Core::Color in der ein Enum mit Farben ist und drei einfache Methoden. Wenn ich jetzt in einem Header eine Farbe aus Color verweden möchte (Als Strd. Parameter) kommt folgender Fehler:
error C2027: Verwendung des undefinierten Typs "Lib::D3D::Core::Color"Meine Forward-Declaration:
namespace Lib { namespace D3D { namespace Core { class Color; } } }Klasse Color:
namespace Lib { namespace D3D { namespace Core { class Color{ enum _D3DCOLOR{ Red = D3DCOLOR_XRGB(0xFF, 0x00, 0x00), ...Verwendung:
static void Rectangle(..., D3DCOLOR Color = D3D::Core::Color::Grey);MfG SWW13
-
SWW13 schrieb:
Hab die Klasse Lib::D3D:Core::Color in der ein Enum mit Farben ist und drei einfache Methoden. Wenn ich jetzt in einem Header eine Farbe aus Color verweden möchte (Als Strd. Parameter) kommt folgender Fehler:...
Sobald du auf einen Member oder eine Funktion zugreifst, reicht eine Forward-Deklaration nicht mehr aus.
Hier gibt es mindestens drei Optionen zu Lösung:
a) Du musst doch inkludieren (sofern möglich).
b) Du lebst damit hier nicht den Enum zu verwenden, sondern ein konstanten Wert.
c) Du lagerst das enum aus der Klasse aus, und inkludierst dieses in beiden Dateien.
-
So jetzt tut endgültig alles, nochmal Danke an alle! Das mit den Namespace und Includes ist komplizierter als ich dachte, aber jetzt ist meine Lib sauber aufgeräumt und sortiert.
MfG SWW13
-
Benutzt du VC? Mit GCC hat das "Kreuz-Inkludieren" bei mir nicht funktioniert.
-
wxSkip schrieb:
Benutzt du VC? Mit GCC hat das "Kreuz-Inkludieren" bei mir nicht funktioniert.
Ja, aber es hat bei mir zu ziemlich vielen Problemen geführt...
Ausserdem war die Lib mit den vielen Includes gut 11mb groß, jetzt sind es nur noch rund 5,7mb. Das mit den Kreuz-Includes scheint ein ganz schlechter Stil zu sein, werd ich auch in Zukunft nie wieder machen. Aus Fehlern lernt man ja schließlich.
Mich wundert nur, dass VC keine Warnung aus gibt, meckert doch sonst immer an allem rum.MfG SWW13
-
GCC gibt ja bei einfachem Kreuz-Includen von 2 Headern über 50 Fehler aus, und zwar immer die gleichen, weil es sich ja wiederholt beim Includen.
Zumindest wars bei GCC 3.4.5 so, da hab ichs mal nämlich selbst aus Versehen gemacht.
-
wxSkip schrieb:
GCC gibt ja bei einfachem Kreuz-Includen von 2 Headern über 50 Fehler aus, und zwar immer die gleichen, weil es sich ja wiederholt beim Includen.
Zumindest wars bei GCC 3.4.5 so, da hab ichs mal nämlich selbst aus Versehen gemacht.Dann macht gcc was falsch.
-
wxSkip schrieb:
GCC gibt ja bei einfachem Kreuz-Includen von 2 Headern über 50 Fehler aus, und zwar immer die gleichen, weil es sich ja wiederholt beim Includen.
Zumindest wars bei GCC 3.4.5 so, da hab ichs mal nämlich selbst aus Versehen gemacht.Gegenfrage: Includeguards sind bekannt, und werden benutzt?
-
asc schrieb:
wxSkip schrieb:
GCC gibt ja bei einfachem Kreuz-Includen von 2 Headern über 50 Fehler aus, und zwar immer die gleichen, weil es sich ja wiederholt beim Includen.
Zumindest wars bei GCC 3.4.5 so, da hab ichs mal nämlich selbst aus Versehen gemacht.Gegenfrage: Includeguards sind bekannt, und werden benutzt?
Nein.
Ist ne Idee, aber das ist keine Library, also muss ich halt für mich selbst wissen, was ich include und was nicht.
-
wxSkip schrieb:
asc schrieb:
Gegenfrage: Includeguards sind bekannt, und werden benutzt?
Nein.
Ist ne Idee, aber das ist keine Library, also muss ich halt für mich selbst wissen, was ich include und was nicht.Das hat nichts mit Library zu tun. Includeguards sollte man immer nutzen.
Beispiel:
// Header a.h #ifndef A_HEADER // <-- Muss eindeutig sein #define A_HEADER // <-- Eigentlicher Headerinhalt. #endif