Native C++ besser mit C++/CLI oder C#?

[Unbe Kant]

Hallo allerseits

Wir planen eine neues Projekt "from scratch". .NET als Präsentationsschicht ist beschlossene Sache, ebenso wie natives (unmanaged) C++ als Business-Schicht oder wenigstens in Form einer eine C++-Klassenbibliothek für leistungskritische Operationen. Obwohl wir eine breite Wissensbasis sowohl in C++ als auch in C# vorweisen können, fehlt uns die Erfahrung bez. der Interoperabilität. So stellen sich uns folgende Fragen:

• Wenn ich es richtig verstehe, wurde C++/CLI eingeführt, um bestehenden Code möglichst einfach zu modernisieren.
  FRAGEN:
  1. Wenn man allerdings, wie wir, "from scratch" beginnt, sollte man dann lieber gleich C# statt C++/CLI benutzen und C# mit den nativen C++-Objekten kommunizieren lassen?
  2. Ich nehme an, dass, wenn alle leistungskritischen Berechnungen von nativen DLLs durchgeführt werden, es keinen Unterschied machen sollte, ob die Präsentationschicht in C# oder C++/CLI implemeniert ist?
  
  
• Eine native C++-Klasse wird innerhalb eines C++/CLI-Objekts wie folgt mit new (und nicht etwa gcnew) instanziiert:
  
  

  myScope::BusinessClass* pBs = new std::BusinessClass();

  FRAGEN:
  1. Ist der so allokierte Speicher gemanaged? 2
  2. Ist das Objekt ein C++- oder ein .NET-Objekt?
  3. Gibt es einen Performanceverlust im Vergleich zu einem in einem nativen Objekt instatziierten Objekt dieser Klasse, z.B. durch irgendwelchen Overhead?
  
  
  
• Es ist also möglich, ein Objekt aus einer native Klasse innerhalb eines gemanagedten C++/CLI-Objekt direkt zu instanziiren.
  
  FRAGEN:
  1. Ist es überhaupt empfehlenswert, aus der nativen Klasse im managed Objekt direkt zu instanziieren? Oder sollte man besser eine native Wrapperfunktion benutzten, in welcher aus der nativen Klasse instanziiert wird?
  2. Kann in C# ein natives Objekt überhaupt instanziiert werden? Oder kann C# nur einfache native Funktionen verwalten?

So, das sind doch nun einige Fragen und ich habe keine Zweifel, dass diese in diesem Forum am besten aufgehoben sind!

Besten Dank für jede Antwort im Voraus!
U. Kant

[Ralf Jansen]

Wenn ihr wirklich "from scratch" beginnt solltet ihr euch sehr genau überlegen ob ihr die beiden Welten(managed/unmanaged) wirklich mischen wollt. Die Überwindung der Grenze, auch wenn ihr C++/CLI macht und PInvoke damit umgeht kostet Performance und ohne jetzt im Detail zu Wissen was ihr Leistungskritisches in unmanaged C++ machen wollt ist die Wahrscheinlichkeit groß das es mehr Leistung kostest als es Performancegewinn einbringt

Aber zu euren Fragen

Wenn man allerdings, wie wir, "from scratch" beginnt, sollte man dann lieber gleich C# statt C++/CLI benutzen und C# mit den nativen C++-Objekten kommunizieren lassen?

Von C# aus kann man nur über PInvoke an den unmanaged C++ Teile. Das ist langsam und man ist im Prinzip auf eine reine C Schnittstelle festgelegt. C++/CLR hat direkten Zugriff auf beide Heaps (managed/unmanaged). Ihr solltet also für die Brücke auf jeden Fall C++/CLI vorsehen. DIe GUI kann man aber trotzdem in C# machen.

Ich nehme an, dass, wenn alle leistungskritischen Berechnungen von nativen DLLs durchgeführt werden, es keinen Unterschied machen sollte, ob die Präsentationschicht in C# oder C++/CLI implemeniert ist?

.NET bleibt .NET. Einer Assembly kann man eigentlich nicht ansehen in welcher Sprache sie geschrieben wurde. Macht also keinen Unterschied welche Sprache ihr einsetzt.

Ist der so allokierte Speicher gemanaged?

Nein. new erzeugt ein Objekt auf dem unmanaged Heap. gcnew eins auf dem managed heap.

Ist das Objekt ein C++- oder ein .NET-Objekt?

Ersteres.

Gibt es einen Performanceverlust im Vergleich zu einem in einem nativen Objekt instatziierten Objekt dieser Klasse, z.B. durch irgendwelchen Overhead?

Solange du mit diesem Objekt im unmanaged Bereich bleibst gibts keinen Overhead.

Ist es überhaupt empfehlenswert, aus der nativen Klasse im managed Objekt direkt zu instanziieren? Oder sollte man besser eine native Wrapperfunktion benutzten, in welcher aus der nativen Klasse instanziiert wird?

Ich versteh die Frage nicht ganz. Ihr werdet irgendeine Form von Wrapper brauchen aber einen der eure unmanaged Objekte als managed Objekte mit entsprechend managed Datentypen veröffentlicht damit sie vom .NET Framework aus nutzbar werden. Gegenüber unmangaed Datentyp ist das Framework blind.

Kann in C# ein natives Objekt überhaupt instanziiert werden? Oder kann C# nur einfache native Funktionen verwalten?

Wie oben schon erwähnt aus C# heraus geht nur PInvoke.
Nur C++/CLR kann direkt mit beiden Objektentypen umgehen. Das heißt aber nicht das die dort einfach so austauschbar wären.

Ihr werdet jede Menge Konverterungsfunktionen brauchen um die Daten von einer Welt in die andere und zurück zu bringen. Heißt ihr müßt sie zwischen den beiden Heaps verschieben und dabei falls notwendig konvertieren.
Die einzigen Datentypen die mir aber gerade einfallen der nicht groß konvertiert werden müßen wären Integertypen. Alles andere also z.B std:string(nach System.string), Enums(nach Enum class), booleans etc. müßt ihr konvertieren.