spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »"dot"«

du kannst das gewünschte verhalten in C++ mit abstrakten klassen und dlls viel "sauberer" implementieren (ganz ohne wirrwarr von GUIDs und CLSIDs etc. ).

Das ist ein Trugschluß, denn das geht mit C++ ganz und gar nicht. C++ hat das Problem, keinen Binärstandard zu definieren. Wenn Du Klassen in DLLs exportierst, kann ich diese DLLs beispielsweise mit meinen Werkzeugen nicht benutzen. Das Problem hast Du selbst mit statischen Libraries. Selbst die Installation eines Service-Packs kann Dir alles zunichte machen. Wenn das alles sicher funktionieren soll, kannst Du nur C-Style Funktionen exportieren (die auf gar keinen Fall Exceptions wefen dürfen). Und wehe, wehe Du forderst im Objekt Speicher an, den der Aufrufer wieder freizugeben hat (Problem, wenn einer der beiden Teilnehmer gegen die statische CRT linkt) ...

Ich erstelle DLLs dann, wenn ich sie in mehreren Projekten verwenden möchte oder auch dann, wenn ich Funktionalität dritten zur Verfügung stellen möchte. Das funktioniert mit reinem C++ ganz und gar nicht (jedenfalls nicht binär, nur auf Quell-Ebene).

Das Problem löst COM eben durch die Definition eines Binär-Standards. Du kannst Objekte öffentlich machen und diese dann in nahezu allen Sprachen nutzen. Exceptions nach COM-Art sind auch kein Problem, da der Mechanismus klar geregelt ist. Auch kann die COMponente Speicher anfordern den der Aufrufer freigibt, alles klar geregelt, usw..

Ich kann nicht sehen, daß hier etwas "sauberer" oder "unsauberer" gelöst ist, da COM ein ganz und gar anderes Ziel hat (oder, seit .NET, hatte. COM funktioniert aber wenigstens, nicht wie .NET, locker bis 95A herunter).

ich weis.

evtl. hab ich mich ein bisschen falsch/undeutlich ausgedrückt

Zitat

wenn es nur darum geht eine engine in/für c++ zu schreiben...

du kannst das gewünschte verhalten in C++ mit...

ich wollte damit eigentlich sagen, dass abstrakte klassen und dlls für seinen anwendungsfall einer simplen c++ engine (hoffe ich hab da nicht was falsch verstanden, bezüglich was T-Virus zu erreichen beabsichtigt) imo die bessere wahl sind/gleiche flexibilität bei weniger aufwand bieten als wenn er sich mit COM herumschlägt, weil ich nicht den eindruck hatte, dass er vorhätte diese engine unter anderen sprachen/compilern zu nutzen.

es ist ein ziemlich verbreitetes vorgehen, eine spieleengine in mehrere subsysteme (grafik, sound, input, ...) aufzuspalten die jeweils in verschiedenen dlls liegen und über interfaces untereinander und mit dem client (spiel) kummunizieren.
der zweck ist hier nicht kompatibilität zu anderen sprachen/compilern, sondern z.b. dass man von einem interface verschiedene implementierungen haben kann (z.b. einen Software, einen OGL und einen D3D renderer) und diese einfach updaten kann ohne andere teile neu zu kompillieren.
ich ging in meinem post davon aus, dass er genau das erreichen will.

mit "sauberer" meinte ich, dass die class/dll variante natürlicher/einfacher/direkter, weil "reines" C++, zu handhaben ist.
denn es steckt viel mehr dahinter als einfach von IUnknown abzuleiten und dann compile zu klicken.
außerdem läuft COM (afaik!!!) nur unter windows oder!?

Zitat von »"dot"«

evtl. hab ich mich ein bisschen falsch/undeutlich ausgedrückt

Möglich. Jedenfalls läuten bei mir alle Glocken, wenn ich "C++" und "DLL" in einem Satz lese, denn das schliesst sich gegeneinander aus.

Wenn ich das will, was Ihr wohl wollt, setze ich auf statische Libraries. Diese, vorhanden im aktuellen Projektbaum, erlauben mir dann das Auifbrechen in verschieden Funktionalitäten. Dadurch, daß diese nicht öffentlich sind und das Haupt-Projekt in Frage entsprechende Dependencies gesetzt hat, ist das auch handhabbar, IMO.

In DLLs hat das aber garantiert nichts zu suchen, und da sind wir uns glücklicherweise einig.

Ich hoffe, ich habe es nicht schon wieder falsch verstanden.

Zitat

außerdem läuft COM (afaik!!!) nur unter windows oder!?

Jawoll, ja, genau so ist das.

der nachteil statischer libraries ist aber eben das statische linken. du musst bei jeder änderung in einer library, die exe neu ausliefern.
falls du so etwas wie z.b. ein plug in system realisieren willst, kannst du damit einpacken.

bei der von mir vorgeschlagenen lösung würden keine klassen in eine dll exportiert (mit __declspec(dllexport)), sondern eine dll erstellt die eine normale c funktion (CreateInterface() oder so) enthält die einen zeiger auf eine instanz der in der dll befindlichen implementierung eines interfaces zurückgibt.

dabei handelt es sich afaik um eine sehr übliche vorgehensweise (is nicht so dass ich der einzge bin der das verwendet.)

das problem ist natürlich, dass wie bereits gesagt verschiedene compiler unterschiedliche binärrepresentationen (vor allem bezüglich vtable etc.) haben können, was aber, wie du ebenfalls gesagt hast, bei libs nicht anders ist. (das mit den libs wusste ich ehrlich gesagt gar nicht/hab mich nie wirklich damit beschäftigt, weil bisher ich nie nen anderen compiler als MSVC++ verwenden musste )
vorteil dieser methode ist aber, dass die einzelnen komponenten als separate dateien vorliegen. natürlich mit dem nachteil eines virtuellen funktionsaufrufes.

dein spiel läuft mit dx8 renderer? schreib eine neue implementierung von renderer.dll für dx9 und dein spiel unterstützt auf einmal shader model 3.0. ohne neu kompillieren des ganzen projektes, ohne ausliefern einer neuen exe.
und vor allem lässt sich das ganze z.b. auch nach linux portieren (natürlich nur wenn die schnittstellen "sauber" sind).

dein model viewer soll erweiterbar sein?
kein problem schreib eine dll und auf einmal kann er *.md3 auch laden...

Zitat von »"dot"«

bei der von mir vorgeschlagenen lösung würden keine klassen in eine dll exportiert (mit __declspec(dllexport)), sondern eine dll erstellt die eine normale c funktion (CreateInterface() oder so) enthält die einen zeiger auf eine instanz der in der dll befindlichen implementierung eines interfaces zurückgibt.

Aber genau das mache ich doch auch, nur benutze ich eben einen klar definierten Weg: COM. Meine C-Style Funktion heißt DllGetClassObject und liefert die Implementierung meiner IClassFactory. Und wenn das Objekt erstmal erstellt ist, hänge ich, genau wie Du, direkt an der vtable, ohne zusätzlichen Overhead (gut, je nach Apartment, aber da passe ich schon auf ). Und das Beste: Das funktioniert garantiert, wenn auch nur unter Windows, was vielleicht nachteilig zu werten ist.

Ansonsten sehe ich statische Libraries nicht so sehr als Problem (solange sie bei mir bleiben). Ich kann auf alle Fälle in mehrere logische Blöcke teilen, was die Übersicht erhöht. Und wenn ich sehe, was heutzutage zum Zeitpunkt des Linkens an Optimierungen möglich sind, freue ich mich gleich nochmal (und wenn es nur Funktionslevel-Linking ist). Klar, wenn es dumm läuft muß ich komplett rebuilden. Ich weiß dann aber, daß alles passt.

Nehme einfach mal eine Methode an, die als Argument einen std::string entgegennimmt. Du lieferst das Produkt aus. Jetzt installierst Du ein Service Pack für Deine Entwicklungs-Umgebung, updatest Deine DLL lieferst nur diese nach. Wenn es dumm läuft, schleicht sich jetzt eine (binäre) Inkompatibilität ein, die dafür sorgt, daß das ganze Programm mit Pauken und Trompeten knattern geht. Wenn der arme Mensch nicht vorher die alte Dll gesichert hat, hat er jetzt gar nichts mehr, muß er etwas anderes zocken.

Ich hingegen habe durch den kompletten Rebuild korrekte Funktion sichergestellt. Vielleicht bin ich auch von berufs wegen etwas überängstlich, aber ich habe halt auch schon jede Menge, Verzeihung, Scheiße erlebt.

ich weis dass das was ich beschrieben hab praktisch das gleiche tut wie COM.

und ich will ganz sicher nicht den nutzen und sinn von COM in frage stellen!

ich wollte lediglich darauf hinweisen, dass es eine (nicht ganz unübliche) alternative zu COM gibt, die ihm den lernaufwand ersparen würde

das problem mit den inkompatibilitäten ist natürlich nicht zu vernachlässigen, ich persönlich hatte aber noch nie etwas dergleichen.

gegen statische libs ist natürlich auch nichts einzuwenden.
nur würde ich nie eine komplette engine in statische libs packen, da die lösung mit dlls imho die bessere ist.

Zitat von »"T-VIRUS"«

Aber was denkt ihr dazu?

Da unterhalten sich zwei, die beide nicht wissen wovon sie sprechen. Nur so viel:

- Für PlugIns ist COM praktisch, aber logischerweise nicht Pfilcht. Prominentes Beispiel ist WinAMP, jedenfalls bis Version 2.78. Als ich das PlugIn für meine Fernbedienung geschrieben habe, habe ich COM nirgendwo anfassen müssen. Wie es in den heutigen Versionen aussieht, weiß ich aber nicht. Du siehst: Nur die Anwendung bestimmt die PlugIn-Schnittstelle. Wenn dabei auf COM gebaut wird, muß Du COM verwenden und wenn nicht, dann nicht.

- CFileDialog benötigt intern nicht COM. Intern wird direkt auf comdlg32.dll gebaut, nicht der Umweg über comdlg32.ocx genommen (letzteres ist der COM-Wrapper um die CommonDialogs)

- Da COM nur einen Binärstandard und keinen Sprachstandard darstellt, lassen sich COM Objekte logischerweise auch in C schreiben. Das, was C++ automatisch macht, muß man halt händisch nachbilden. Richtig viel Arbeit, aber das funktioniert sehr wohl.

- Standard schreibt sich mit d am Ende.