#includes bei Vererbung "verstecken"

[Memorius]

Hallo zusammen,

ist mein erster Post hier und ich hoffe ich mache alles richtig. Habe nichts bei Google oder der Suchfunktion hier gefunden, tut mir leid wenn ich zu doof zum richtig Suchen war..

Mein Problem:
Ich schreibe ein Spiel mit C++ in Visual Studio 11. Dabei möchte ich die Engine und das die Engine nutzende Hauptprogramm trennen (z.B. um die Engine auch in anderen Projekten verwenden oder sie sogar anderen weitergeben zu können). Ich arbeite also an zwei getrennten Projekten - einmal die 3D Engine, welche als statische Bibliothek kompiliert wird, und einmal das Hauptprogramm welches die .lib einbindet.

Nun benutze ich in der Engine einige Bibliotheken, z.B. für OpenGL, Fenster und mathematische Funktionen. Die Header dieser Bibliotheken binde ich in den Code der Engine ein, wo sie gebraucht werden. Im Hauptprogramm #include ich einige Header aus meiner Engine, um von deren Klassen zu erben. Dabei erlange ich aber über die Header auch Zugriff auf die von der Engine #includierten Bibliotheken. Das finde ich aber nicht besonders schön - ich möchte gerne, dass der Benutzer der Engine nur solche Funktionalität über meine Header bekommt, die ich ihm auch gewähren will. Wenn der Nutzer meine Bibliothek einbindet soll er nicht auch gleich OpenGL Funktionen als Vorschlag in VS zu Gesicht bekommen. Und eigene Klassen, die in meiner Bibliothek #includiert werden, aber den Nutzer nichts angehen, sollte er auch nicht sehen. Das ist mein Problem, ich hoffe es ist versändlich.

Ich habe auch versucht , die #includes möglichst nicht in meine Header der Engine zu schreiben, sondern in den .cpp File und im Header stattdessen eine Vorwärtsdeklaration der verwendeten Klassen zu schreiben. Das ist aber nicht immer möglich wie es scheint, z.B. wenn ich ein Memberobjekt einer fremden Klasse in meiner Klasse habe.

//Entity.h

class Model;

class Entity {
private:
  Model model;
  ...
}

Da erscheint dann der Fehler:

error C2079: 'Entity::model' verwendet undefiniertes class 'Model'

. Oder auch wenn ich fremde Elemente nutze, die in einem Namespace liegen. Z.B. habe ich eine Methode

void setPosition(glm::vec3 pos);

, welche eben die vec3 Klasse der glm Bibliothek verwendet. Wenn ich NICHT "glm/glm.hpp" in meinem Header einbinde, wie kann ich dann das Argument glm::vec3 pos im Methoden Prototyp benutzen?

Vielen Dank im Voraus.

Grüße,
Memorius

[Sone]

Du suchst (auch speziell bei deinem Beispiel) das Pimpl-Idiom.
Beispiel bei Wikipedia.

[cooky451]

Das folgt aus generellem Fehldesign im C++ Kompilierungs-Modell, pimpl und/oder Vererbung helfen.

[Memorius]

Danke, das schau ich mir mal an.

Grüße,
Memorius

[hustbaer]

cooky451 schrieb:

Das folgt aus generellem Fehldesign im C++ Kompilierungs-Modell, pimpl und/oder Vererbung helfen.

Wie soll Vererbung da helfen?
EDIT: Ah, OK, du meinst vermutlich dass man statt die konkrete Klasse bekannt zu machen nur ne abstrakte Basisklasse bekannt macht...

[invpimp]

hustbaer schrieb:

cooky451 schrieb:

Das folgt aus generellem Fehldesign im C++ Kompilierungs-Modell, pimpl und/oder Vererbung helfen.

Wie soll Vererbung da helfen?
EDIT: Ah, OK, du meinst vermutlich dass man statt die konkrete Klasse bekannt zu machen nur ne abstrakte Basisklasse bekannt macht...

Das führt nur dazu, dass der Nutzer selber mit seinem unique_ptr pimpeln muss, verhindert nachträgliche Optimierungen wie pimpl rückgängig machen und hat Runtime Overhead.

Vererbung an sich ist keine Lösung für das #include-Problem.

[knivil]

Das folgt aus generellem Fehldesign im C++ Kompilierungs-Modell

oder

#include-Problem

Mag mich wer aufklaeren, warum Fehldesign oder include-Problem?

[gotw]

http://www.gotw.ca/gotw/024.htm

Andere Nutzer kauften auch:
- Buildzeitproblem
- Headerabhängigkeitsproblem

[knivil]

gotw schrieb:

http://www.gotw.ca/gotw/024.htm

Andere Nutzer kauften auch:
- Buildzeitproblem
- Headerabhängigkeitsproblem

1.) Lol, nie gehabt ... nein ich arbeite nicht an Spielzeugprogrammen
2.) nutze Pimpl