3. Klasse nicht korrekt eingebunden

Klasse nicht korrekt eingebunden

  • L

    Aber das ist die einzige Einbindung von GLTexture.h. Später in GLFlatAnimObject.h ist es, obwohl es inkludiert wird, nicht mehr erwähnt, da hat der Präprozessor es tatsächlich komplett übersprungen. Aber vor dieser Einbindung, welche ich hier gepostet habe, wurde es nicht eingebunden. Die gepostete Stelle ist die einzige Stelle, in der es in der Präprozessorausgabe auftaucht.

    0

  • Beispiel:

    A.h inkludiert gleich am Anfang B.h.
    B.h braucht Dinge aus A.h und inkludiert daher wieder A.h.
    A.h wird nun aber übersprungen, da es schon inkludiert wurde.
    D.h. in B.h gibts kein A.h obwohl es eigentlich gebraucht wird. Erst nach B.h kommt der eigentliche Inhalt von A.h, aber dort ist es zu spät.

    0
  • Mod

    Es sieht, sofern deine Beiträge der Wahrheit entsprechen, tatsächlich nicht nach zirkulärer Einbindung aus. Wird vielleicht fälschlicherweise irgendwo ein anderes GL_TEXTURE definiert? Ich könnte mir gut vorstellen, dass dies eventuell sogar durch die OpenGL-Header selbst geschehen könnte. Nenn das Makro doch testhalber irgendwie anders, z.B. GL_TEXTURE_ABC_123_BLABLA

    0
  • L

    Ja, das Prinzip kenne ich. Aber GLTexture.h benötigt keine anderen Dateien aus dem Projekt und inkludiert auch keine (die inkludes von GLTexture.h stehen in meinem letzten Post, nur string, SDL_image und SDL_opengl).
    Und GLTexture.h wird nur von GLFlatAnimObject.h und von GLSystem.h inkludiert.
    Habs jetzt noch einmal GLTexture.h ganz ans Ende von GLSystem.h gesetzt.
    Aber an dem Problem hat das nichts geändert. GLTexture.h wird nun halt erst ganz am Ende das erste mal im Präprozessor erwähnt, wird aber wieder übersprungen.

    0
  • L

    Tatsache. Mit GL_BLUBB hat das Programm kompiliert. Da hat mich OpenGL wohl auf den Arm genommen.

    Vielen Dank SeppJ! 🙂

    Und natürlich auch dir vielen Dank dot! 😉

    0
  • Mod

    Jaja, die Makros 😃 . Da sieht man mal wieder die Gefahren. Daher möglichst Makronamen benutzen, die ziemlich sicher niemand sonst benutzen wird. Großschreibung ist übliche Konvention, da dran sollte man sich halten, auch wenn es die möglichen Namen einschränkt. Was aber gut kommt, sind exotische Prä- oder Suffixe. Das haben sich die Open_GL Entwickler so gedacht und haben alles mit GL_ am Anfang gemacht. Du leider auch 😃 . Was gut kommt, wenn man für sich privat entwickelt sind zum Beispiel die eigenen Initialen als Präfix. Oder eine Abkürzung des Projektnamens.

    Guckst du zum Beispiel hier das Problem 1 an:
    http://www.boost.org/doc/libs/1_47_0/libs/preprocessor/doc/index.html

    0

  • Was noch besser kommt: namespace 😉

    EDIT: Oh, Makros...pööööhse

    0
  • L

    Ja, da meine Engine auf OpenGL basiert, hab ich sie einfach GL-Engine genannt. Mein Makrobeginn war dann halt GL_ 😃 . Bei Version Zwei (irgendwann einmal) werd ich vielleicht alles Umbenennen und andere Präfixe verwenden. 😉

    0

  • Oder noch besser: Namespaces verwenden und auf Makros verzichten 😉

    0
  • Mod

    dot schrieb:

    Oder noch besser: Namespaces verwenden und auf Makros verzichten 😉

    MAch mir mal vor, wie du das bei Include-Guards machen willst.

    0

  • #pragma once :p

    Bei Includeguards braucht man natürlich Makros. Aber dabei kann man ja eine anständige Konvention verwenden, wie z.B. FILENAME_INCLUDED oder sowas...

    0
Anmelden zum Antworten