3. "Problem" mit #include

"Problem" mit #include

  • R

    Falls nachschlagen willst, die Konstrukte heissen "include guards" ...

    Ciao ...

    0
  • ?

    Ginge das gleiche nicht auch mit #pragma once?
    aber die beiden sachen sind ja nur "gegen" Mehrfachdeklarationen, die beiden files binden sich jaimmer noch ständig gegenseitig ein.

    0
  • 1

    Tetris Fan schrieb:

    Ginge das gleiche nicht auch mit #pragma once?
    aber die beiden sachen sind ja nur "gegen" Mehrfachdeklarationen, die beiden files binden sich jaimmer noch ständig gegenseitig ein.

    unterschied ist

    #ifndef gibts überall ...

    #pragma compiler spezifisch

    0
  • ?

    ja, aber was ist denn jetzt? die beiden methoden verhindern doch nicht das einbinden der files, so ndern nur mehrfachdeklarationen, oder?

    0
  • 1

    sie verhindern die mehrfachdeklaration siehst du ja es überprüft ob die variable defined ist wenn net geht es in den if zweig und defined die variable als allererstes ... 🤡

    0
  • R

    Naja, auf diue Loesung bist ja schon fast selbst gekommen ...

    1a. ueberdenk noch mal die Abhaengigkeiten !!! Brauchst die wirklich so ?
    1b. du kommst dann ohne forward deklaration ned weiter.
    1c. normalerweise braucht man forward deklarationen fuer friend deklarationen und fuer die pimpl geschichte (aufloesung von abhaegigkeiten).

    vertex buffer ist stark abhaengig von grafik, und grafik ist stark abhaengig von vertex. klingt sehr vielversprechend.
    Versuch dein klassendesign ein bisserl zu abstrahieren ... Zustaendigkeiten zu verteilen, Schnittstellen definieren etc. Schau dir Designmuster an !

    Ciao ...

    0
  • H

    Hallo,
    vielleicht hilft ein Beispielablauf.
    Angenommen du hast zwei Header A.h und B.h, die sich gegenseitig inkludieren, aber beide mit Include-Guards versehen sind.
    Der Ablauf ist jetzt der folgende (die Reihenfolge ist willkürlich gewählt)
    1. Öffne A.h
    2. Lese die Datei zeilenweise:

    #ifndef A_H__INCLUDED

    A_H__INCLUDED ist nicht definiert, also weiter:

    #define A_H__INCLUDED

    Ok. Für die aktuelle Übersetzungseinheit (nennen wir sie foo) ist das Symbol A_H__INCLUDED nun definiert.

    #include "b.h"

    Die include-Anweisung wird bearbeitet.
    3. Öffne b.h
    4. Lese die Datei Zeilenweise

    #ifndef B_H__INCLUDED

    B_H__INCLUDED ist nicht definiert, also weiter:

    #define B_H__INCLUDED

    Ok. Für die aktuelle Übersetzungseinheit (nach wie vor foo) ist nun auch das Symbol B_H__INCLUDED definiert.

    #include "a.h"

    5. Öffne A.h
    6. Lese die Datei Zeilenweise

    #ifndef A_H__INCLUDED

    Das Symbol A_H__INCLUDED ist für diese Übersetzungseinheit bereits definiert. Die Bedingung ist also nicht erfüllt.

    Nachfolgende Zeilen werden jetzt solange ignoriert, bis ein #endif auftaucht.
    7. Schließe Datei a.h
    8. Weiter in b.h -> bis zum #endif
    9. Schließe Datei b.h
    10. Weite in A.h (aus 1.) -> bis zum #endif
    11. fertig

    Wie du siehst, schützen die Include-Guards auch vor der unendlichen Rekursion.
    Sie verhindern allerdings nicht, dass sowohl a.h, als auch b.h für eine ÜE *zweimal* geöffnet und *zweimal* komplett gelesen werden. Es wird nur im zweiten Durchlauf alles ignoriert, also insbesondere auch die jeweilige include-Anweisung.

    Ein pragma-once erreicht das gleiche, ist aber effizienter, da jede Datei nur einmal geöffnet und bearbeitet wird. Der Nachteil wurde bereits genannt. pragma once ist nicht portabel, da nicht standard.

    0
  • ?

    ah ja, gut, also müssen die #includes mit in die inclöude guards. ok, danke, werde das mal probieren,
    cya 🙂

    0
  • H

    ah ja, gut, also müssen die #includes mit in die inclöude guards

    Yep. Alles andere ist sinnlos.

    Wenn man ganz viele Header mit vielen Abhängigkeiten hat und es auf Include-Performanz ankommt, sollte man sogar zusätzliche Include-Guards um jede Include-Anweisung einbauen. Damit spart man sich auch das mehrmalige Öffnen und Bearbeiten der Dateien.

    #ifndef A_H__INCLUDED
#define A_H__INCLUDED

#ifndef B_H__INCLUDED
#include b.h
#endif

#ifndef IOSTREAM_H__INCLUDED
#include <iostream>
#define IOSTREAM_H__INCLUDED
#endif
...

#endif

    Naja, aber zuerst sollte man wirklich sicher sein, dass alle Abhängigkeiten auch wirklich nötig sind 🙂

    0
  • ?

    hab das problem jetzt im griff.
    nur um das nochmal zu klären:
    ich denke, die abhängigkeiten sind bei mir recht gut "gelöst", ich habe zuerst daran gedacht, die zeichen routinen in die VertexBuffer Klasse zu packen, jedoch dachte ich dann, dass die aufgabe eines vertex buffer die ist, vertices zu managen, und nicht primitives o.Ä. zu zeichnen. also habe ich diese routinen in die grafik klasse gepackt.
    danke nochmals, cya

    0
Anmelden zum Antworten