2009-02-28 15 views
2

Ich arbeite gerade an einer Sprite-Engine in C++. Ich habe eine abstrakte Klasse IEngine mit einer virtuellen Funktion init_api. Dies nimmt eine Lücke ein *.void * als unbekannter Variablentyp

// Initialise the engines' API 
// api_params - void* to api parameters for initalisation 
// hWnd - window handle 
virtual bool init_api(void* api_params, HWND hWnd) = 0; 

Ich habe dann eine DirectX-Engine-Klasse CEngineDX implementiert. Was dann api_params auf ein D3DPRESENT_PARAMETERS * umsetzt, so dass es zur Initialisierung von DirectX verwendet werden kann.

// Cast api_params to a D3DPRESENT_PARAMETERS 
D3DPRESENT_PARAMETERS* presentParams = NULL; 
presentParams = reinterpret_cast< D3DPRESENT_PARAMETERS* >(api_params); 

Ich bin ganz zufrieden mit diesem Setup aber wollten einige andere Programmierer auf dieser „Lösung“ sehen bekommen, wenn Sie möchten.

Prost für die Antworten!

Carl

Antwort

1

Eine andere Möglichkeit, dies zu tun, ist nur eine gemeinsame Kopfzeile und verschiedene * .cpp-Dateien für jede Implementierung. Auf diese Weise können Sie nur die D3D- oder nur die OGL-Dateien in Ihr Projekt einfügen. IMO ist es besser, die API zur Kompilierungszeit zu wählen, so dass sie nicht mit beiden Bibliotheken verlinkt.

Für die Lücke *, mag ich es nicht wirklich. Ich denke, dass Sie besser Ihre eigenen Typen definieren und sie dann mit Wrapper-Strukturen/Klassen und typedefs den API-Typen zuordnen würden. Sie können diese weiterleiten und die tatsächliche Implementierung in Ihre * .cpp-Dateien einfügen.

Ein weiterer Vorteil dieser Methode ist, dass Sie nicht für virtuelle Funktionen bezahlen, die Sie nicht benötigen, obwohl ich realisiere, dass die Kosten für einen virtuellen Anruf ziemlich gering sind.

1

Dies ist ein relativ häufiges Problem bei der Variation von Argumenttypen in Vererbungshierarchien; Ihre Unterklasse möchte den Typ von 'api_params' von der Elternklasse spezialisieren.

Ich denke, das ist in Ordnung, aber es ist C-like. Ich denke, bessere Lösung wäre, init_api nicht virtuell zu machen und es mit dem richtigen Typ in der Unterklasse zu implementieren. Wie auch immer, am wahrscheinlichsten ist die D3DPRESENT_PARAMETERS Struktur nur mit der DirectX-Engine sinnvoll, warum also nicht in der Unterklasse, zu der sie logisch gehört?

+0

Vielen Dank für Ihre Eingabe. : P –

0

Ich mag diese API nicht wirklich. Warum einen leeren Zeiger verwenden? Warum nicht den ersten Parameter zu einem Zeiger oder Verweis auf D3DPRESENT_PARAMETERS machen? Du weißt, dass es genau das ist, was es ist, oder? Dies ist mehr typsicher.

1

Nun, Sie könnten Vorlagen verwenden (Sie mögen Abbilder), aber Ihre Hierarchie muss in diesem Fall gehen.

template<class T> 
struct Engine { 
    bool init_api(const T& params, HWND hWnd); 
}; 

//specialize for DirectX 
template<> 
struct Engine <D3DPRESENT_PARAMETERS> { 
    bool init_api(const D3DPRESENT_PARAMETERS& params, HWND hWnd) { 
    return true; 
    } 
}; 

Aber, verwenden Sie etwas, das in das große Schema der Dinge passt.

Verwandte Themen