C++ Framework mit C# GUI-Code verbinden
-
David W schrieb:
dot schrieb:
David W schrieb:
sind also die Patterns aus dem GOF Buch keine gute Idee?
Hältst du Singleton für eine gute Idee?
Jup.
Singleton ist natürlich an sich weder gut noch schlecht. Das Problem ist wieder wie es verwendet wird. Und das wird es leider in 100% (nein, nicht 99.9999%) aller Fälle, die ich bisher je gesehen hab, falsch, obwohl es im GoF Buch richtig steht.
Aber die Diskussion hatten wir hier schon oft genug
-
@dot,
Das halte ich für keine gute Idee. Man verwendet die Bibliothek dann meistens nicht nur in diesem Programm. Willst du jedesmal nach C++/CLI greifen und die Logik dort implementieren? Dann musst du auch die anderen Bibliotheken, welche mit dieser interagieren, in C++/CLI verwenden. Am Ende machst du immer alles in C++/CLI und nur gerade das GUI in C#. Ich würde sagen, dass wird recht wartungsunfreundlich.Die darunterliegende Bibliothek sollte sich zudem nicht all zu stark verändern. Man wrappt ja normalerweise stabile Versionen. Dadurch verändert sich über die Zeit nicht all zu viel.
@hustbaer,
Ich bin davon ausgegangen, dass er eine C Schnittstelle schon anbietet, da er diese ja bereits implementieren wollte. Von daher wird er diese sowieso machen und der Aufwand ist dann gleich.In anderen Fällen hast du natürlich recht, dass man noch eine C Schnittstelle entwerfen muss.
Zum Marshaling:
Strings und Arrays ja. Ich empfand das als recht mühsam in C++/CLI. Ich hatte aber auch viele Strings zu verarbeiten bei meiner letzten Begegnung mit C++/CLI und dann auch noch zum Teil über unterschiedliche Encodings. Über P/Invoke empfand ich dies als wesentlich angenehmer.@David W,
Die GOF Leute würden das Singleton Pattern heutzutage rausnehmen, wenn sie das Buch nochmals schreiben würden.
(Finde gerade die Quelle nicht mehr, aber war eine Aussage von einem der vier und wenn ich mich recht erinnere, hatte er mit 2 der anderen darüber gesprochen)Grüssli
-
Dravere schrieb:
@dot,
Das halte ich für keine gute Idee. Man verwendet die Bibliothek dann meistens nicht nur in diesem Programm. Willst du jedesmal nach C++/CLI greifen und die Logik dort implementieren? Dann musst du auch die anderen Bibliotheken, welche mit dieser interagieren, in C++/CLI verwenden. Am Ende machst du immer alles in C++/CLI und nur gerade das GUI in C#. Ich würde sagen, dass wird recht wartungsunfreundlich.Ich weiß nur, dass ich mir bisher jedes Mal, wenn ich was gewrapped hab, früher oder später gewünscht hab, dass ich es nicht gewrapped sondern abstrahiert hätte. Und zwar eigentlich sogar ganz unabhängig davon, in welcher Sprache ich grad unterwegs war. Darum meine Empfehlung nicht zu wrappen sondern zu abstrahieren
Mag natürlich sein, dass das daran liegt, dass es sich dabei praktisch immer um irgendwelche low-level APIs gehandelt hat...
-
Also, der Klarheit halber:
- Das C++-Framework ist in native C++ geschrieben, ist aber noch in der Entwicklung. Das heißt, es ändert sich noch, wobei die Schnittstellenklassen erstmal größtenteils fertig sind, nur die Zahl der möglichen Events wird noch deutlich wachsen.
- Die Logik-schicht im Framework wird nicht in C++/CLI geschrieben. Heißt, wie hustbaer sagt, dass eine C++/CLI-Schicht ein reiner Adapter wäre, um auf die native Schnittstelle aus .NET zugreifen zu können.
- Wenn ich aber irgendwann
die C-API sowieso zur Verfügung stellen möchte, ist es doch relativ wurscht, ob ich den .NET-Adapter auf der C-API (in C#) oder auf dem Framework selber (in C++/CLI) aufsetze oder?
Die Schnittstellen des Frameworks sind relativ simpel gehalten. Ich könnte mir vorstellen, die C-API und evtl. auch den .NET-Adapter zu ~90% generieren zu lassen.
-
Was fehlt ist die Performance-Betrachtung. Zu dem Thema sagt die MSDN:
http://msdn.microsoft.com/en-us/library/ky8kkddw.aspx
http://msdn.microsoft.com/en-us/library/aa712982.aspx
PInvoke has an overhead of between 10 and 30 x86 instructions per call. In addition to this fixed cost, marshaling creates additional overhead. There is no marshaling cost between blittable types that have the same representation in managed and unmanaged code. For example, there is no cost to translate between int and Int32.
For higher performance, it may be necessary to have fewer PInvoke calls that marshal as much data as possible, rather than have more calls that marshal less data per call. Or somewhat more memorably: prefer a chunky over a chatty API.
-
loks schrieb:
Was fehlt ist die Performance-Betrachtung.
Ist in meinem Fall weitgehend irrelevant, da ich
- Nur eine GUI an meine Client-Schnittstelle flanschen will (oder nenn es den View im MVC Pattern). Das heißt, durch die Schnittstelle zwischen C# und C++ gehen nur die User-Interaktionen und die Events, die als Reaktion auf diese Interaktionen zurückkommen
- Das Ganze nur als Testsystem zum rumspielen haben will, d.h. es wird keine Produktiv-Anwendung sein, die unter Schwerlast läuft oder extrem skalieren muss.
