3. Namespace wird nicht gefunden

Namespace wird nicht gefunden

  • Mod

    SWW13 schrieb:

    Wenn ich so ein "using namespace x;" in einem Header hab und den irgendwo einbinde, gelten die using-Direktiven dort dann auch?

    Ja, genau das ist das Problem.

    Gibt es so eine Art "Richtlinie", was die Namespaces angeht, also wie man die am besten in z.B. eine Lib verpackt oder was man nicht machen sollte?

    1. ⚠ Niemals using in Headern verwenden, die auch von anderen Leuten benutzt werden!
    2. Bibliotheksnutzer freuen sich, wenn die Funktionalität deiner Bibliothek in einem eigenen Namensraum liegt und nicht im globalen.

    0
  • ?

    SWW13 schrieb:

    Wenn ich so ein "using namespace x;" in einem Header hab und den irgendwo einbinde, gelten die using-Direktiven dort dann auch?

    #include ist eine reine Text-Substitution. Der Präprozessor öffnet die Header-Datei, liest den gesamten Inhalt ein, und ersetzt deine "#include" Anweisung mit dem kompletten Inhalt der Datei.

    0
  • A

    SWW13 schrieb:

    Gibt es so eine Art "Richtlinie", was die Namespaces angeht, also wie man die am besten in z.B. eine Lib verpackt oder was man nicht machen sollte?

    Falls du damit auf die Hierarchie ansprichst, gibt es verschiedene Wege. Eine Variante ist z.B. <Firma/Projekt>::<Bereich>::<Schicht>, aber es gibt auch viele andere sinnvolle (Wobei der Projektname oder ein Kürzel hierfür auf der untersten Ebene schon fast Standard ist, wenn man sich diverse Bibliotheken anschaut).

    0
  • S

    Danke für die zahlreichen und schnellen Antworten, ich werde versuchen das zu beachten.

    Allerdings hab ich immer noch ein Problem und zwar:
    Wenn ich eine Klasse X in einer anderen Klasse verwende (als Object) z.B. "Lib::D3D::Core::FontManager *myFontManager;" bekomme ich immer noch den Fehler, dass Core nicht gefunden wurde und keine Namespace sei. Wenn ich ein class als Forward-Declaration davor schreib bleibt der Fehler bestehen. Eine Idee woran es liegt?

    P.S.: In der .cpp Datei funktioniert es, bloß hilft es mir da nicht weiter. 😞

    MfG SWW13

    0
  • A

    SWW13 schrieb:

    Allerdings hab ich immer noch ein Problem und zwar:
    Wenn ich eine Klasse X in einer anderen Klasse verwende (als Object) z.B. "Lib::D3D::Core::FontManager *myFontManager;" bekomme ich immer noch den Fehler, dass Core nicht gefunden wurde und keine Namespace sei.

    Wirklich als Objekt, nicht als Zeiger?

    Bei ersteren muss du die Datei auch inkludieren, bei letzteren musst reicht eine Forward-Declaration. Aber in letzteren Fall musst du weiterhin an die Namensräume denken.

    SWW13 schrieb:

    Wenn ich ein class als Forward-Declaration davor schreib bleibt der Fehler bestehen. Eine Idee woran es liegt?

    Sieht diese auch wie folgt aus?

    //...
// Auch für eine Forward-Declaration ist die gesamte Namensraumangabe nötig
namespace Lib { namespace D3D { namespace Core {
  class FontManager;
}}}

namespace XYZ {
  class X {
    private:
      Lib::D3D::Core::FontManager * myFontManager;
    //...
  };
}
//...
    0
  • S

    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

    0
  • W

    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?

    0
  • S

    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

    0
  • A

    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.

    0
  • S

    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

    0
  • W

    Benutzt du VC? Mit GCC hat das "Kreuz-Inkludieren" bei mir nicht funktioniert.

    0
  • S

    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

    0
  • W

    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.

    0
  • ?

    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.

    0
  • A

    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?

    0
  • W

    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.

    0
  • A

    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
    0
Anmelden zum Antworten