C++/CLI, OpenGL und unmanaged DLL's

mcbastian

Hallo,

ich habe ein kleineres Problemchen, weiß aber nicht genau, wo ich mit suchen für die lösung ansetzen soll.

Ich habe einen recht grossen szenengraphen und einen renderer dafür. Alles schön ordentlich getrennt, nutzt DLLs. Geschrieben im (ANSI kompatiblen) c++ unter massiver zuhilfenahme von der STL (hauptsächlich verschiedenste container), Singletons und Boost (da hauptsächlich signals, threads und tests).
Diese ganze "engine" benutzt auch schöne MFC-DLLs als Plugins. Das funktioniert dann wie folgt:
Man erstellt im VS ein neues MFC-DLL projekt, lässt diese klasse dann noch zusätzlich von der Plugin-Basisklasse der engine erben (für getter, setter und event-handler), implementiert dieser DLL eine "MyInit"-Funktion, packt einenDialog (or whatever) rein und alles läuft.

Jetzt kam mir die überlegung, warum nicht die wunderbare welt von .NET nutzen. zumal man da in sachen GUI-Elementen mehr möglichkeiten hat und schneller zum ziel kommt.

Ich hab mich also mit C++/CLI beschäftigt, bin aber irgendwie nicht so ganz hinter die vermischung von managed/unmanaged gekommen.
Unser softwaresystem besteht aus ca. 200 klassen und annähernd 50000 zeilen. Ich möchte nun nicht für jede klasse einen wrapper schreiben müssen...
bzw. in ca. 300 header-files diverse #ifdefs einfügen

Erreichen will ich folgendes:
zum einen eine ".NET-DLL" analog zu den MFC-DLLs. Wichtig ist aber, dass die ".Net-dll" vollen zugriff auf den Szenengraphen bekommt der da als singleton rumliegt und VIEL STL/BOOST verwendet. sprich, der .net code muss ja teilweise die c++-header der engine inkludieren?!?

zum anderen wäre es nice. in einer .NET-Anwendung eben via dieser engine ein OpenGL-fensterlein zu öffnen (wie es meine MFC-Anwendungen auch können). (das ist aber sekundär, wichtiger wären die ".net-dlls")

Wie gesagt. Änderungen an den Headerfiles bzw. dutzende wrapper-klassen sollen vermieden werden.

Wie würde man hier ansetzen?

Viele Grüße
Bastian

Es gibt da ein paar Bücher zum Thema, sie wurden hier schon mehrmals genannt.

"C++/CLI in Action" von Nishant Sivakumar (Manning)
"Expert C++/CLI" von Marcus Heege (Apress)

Insbesondere Heege beschäftigt sich sehr detailiert mit dem Thema Interfacing.

Schau Dir bei Amazon das Inhaltsverzeichnis an.

Jochen Kalmbach

mcbastian schrieb:

Unser softwaresystem besteht aus ca. 200 klassen und annähernd 50000 zeilen. Ich möchte nun nicht für jede klasse einen wrapper schreiben müssen...
bzw. in ca. 300 header-files diverse #ifdefs einfügen

Erreichen will ich folgendes:
zum einen eine ".NET-DLL" analog zu den MFC-DLLs. Wichtig ist aber, dass die ".Net-dll" vollen zugriff auf den Szenengraphen bekommt der da als singleton rumliegt und VIEL STL/BOOST verwendet. sprich, der .net code muss ja teilweise die c++-header der engine inkludieren?!?

Hmm...

C# kann keine C++-Header includieren...
Vermutlich wirst Du nicht drum rum kommen, für alle "public" Klassen einen Wrapper zu schreiben... dabei solltest Du aber beachten, dass es in .NET *keinen* Desktruktor gibt bzw. dieser nicht-deterministisch arbeitet.
Du musst Dir somit aus sicht eines C# Developers zuerst mal eine Klassenstruktur für Deine Dinge ausdenken und dies dann implementieren. Und eben darauf acht geben, dass die unmanaged-Dinge auch immer korrekt gelöscht werden...

mcbastian

C# kann keine C++-Header includieren...

Das is mir schon klar ich würde eher mit C++.NET entwickeln (obwohl c# definitiv nicht zu verachten ist)
ich hab mir schon die stl.net-container angesehen. sieht alles recht vielversprechend aus. Ich will halt nur mit möglichst wenig "overhead" das "alte" mit dem "neuen" nutzen

Jochen Kalmbach

Wenn Du C++/CLI verwendest, dann kannst Du die bisherigen C++-Klassen einfach so verwenden. Musst nichts grosses dabei beachten...

Vorden

allerdings fällt unter Umständen die Intellisense (also halt unter Visual Studio, ich denke ich gehe von der richtigen IDE aus) weg, passiert mir grad auch eigentlich ständig, freue mich dann, wenn ich mal irgendwas nachlesen kann, das ich benutzen kann.
Jo...
wollte eigentlich eben auch eine Frage zu diesem Thema stellen:
Ich habe ein ähnliches Szenario, hab mir ne Control gebaut, die nen OpenGL-Context enthält. Das läuft ja alles ganz schön, aber was ich mir gerade so für eine Frage stelle ist folgende:
Die Designer-Ansicht stürtzt bei mir recht häufig ab (also habe eine C++/cli dll, welche eben dieses Control beinhaltet, dieses Control ist dann wiederum zum Testen auf einer C#-Form eingebunden). Ich denke die Abstürze des kompletten Visual Studios kommen daher, dass, während der Arbeit mit dem Designer, der OpenGL-Content schon gerendert wird. Das ganze dauert dann auch noch recht lange, also das ziehen des Controls auf die Form, bzw. das Entfernen der Control von der Form.
Weiß irgendwer, wie man dies ausschalten kann, also, dass der Designer eben nicht den OpenGL Context erzeugt etc ? Habe im übrigen den Code für das Erzeugen etc in OnHandleCreated stehen und nicht im Konstruktor, würde da OnLoad mehr Sinn machen oder so was?
Ich hoffe, dass ihr mir auch helfen könntet.

dotnet-dlls sind nicht durchlässig für native types.

man muss also die headers und cpp-files einer mixed-source-library in das projekt einbinden.

mixed source als library geht nur in source-code-form.

und: nein, statische libraries gehen wg. dotnet auch nicht.

sorry