C ++ / CLI ist eine sehr mächtige Sprache. Es ist die einzige CLR-Sprache, in der Sie verwalteten und nicht verwalteten Code nahtlos kombinieren können. Wie viele Softwareentwickler (auf dieser Site) verwenden diese Sprache? In welchen Projekten verwenden Sie es? Ist es eine Anpassung von Legacy-Code oder die Erstellung einer Originalsoftware? Können Sie altes Managed C ++ mit neuem C ++ / CLI vergleichen? Was denkst du über die aktuelle Qualität und über die Zukunft von C ++ / CLI?
Ich habe es verwendet, um dünne Schichten der Integration zwischen verwaltetem und nativem Code zu schreiben. Das ist alles.
Das bekannteste einzigartige Merkmal ist die Fähigkeit, nahtlos in nicht verwalteten Code einzutauchen und jedes Bit des schreibbaren Speichers im gesamten Prozess zu modifizieren (oder versehentlich zu beschädigen) - das ist kein Vorteil bei der allgemeinen Programmierung, aber wenn Sie es brauchen, Es ist großartig. Aber ich denke, ich werde es immer weniger brauchen. Sie können C ++ / CLI mit einem / pure-Flag kompilieren, aber dann wird es wirklich eine völlig neue Sprache.
Es gibt jedoch noch zwei weitere große einzigartige Features:
Destruktoren, die etwas Nützliches tun. In C # ist ein Destruktor ein Finalizer. In C ++ ist es ein richtiger deterministisch genannter Destruktor. Das bedeutet, dass C ++ / CLI über die vollständigste Infrastruktur für das Arbeiten mit IDisposable verfügt. C # hilft nur Clients (über die Anweisung mit ), aber nur C ++ / CLI unterstützt auch Implementierer. Ich bin zuversichtlich, dass C # dieses Feature vielleicht eines Tages aufnehmen wird.
Enttippungsvorlagen, die zusammen mit CLI-Generika verwendet werden können. Eine andere Sache, die in C # sehr nützlich wäre, obwohl sie ohne das historische Gepäck viel nahtloser gemacht werden könnte.
Aber C # ist gut genug, ohne die letzten zwei Dinge, die ich nicht versucht bin, C ++ / CLI allgemein zu verwenden.
Ich habe C ++ / CLI für ein Simulationsprojekt verwendet. Meine Simulations-Engine, die die eigentliche Berechnung ausführt, war eine in C ++ geschriebene Codebasis. Ich brauchte dafür ein GUI-Frontend, das ich erfolgreich in C ++ / CLI programmiert habe.
Aus meiner Sicht ist die Sprache genauso einfach zu programmieren wie C #, allerdings mit einer leichten syntaktischen Peinlichkeit. Das heißt, die Syntax ist viel einfacher als die Managed Extensions Sache, die Microsoft früher entwickelt hat.
Eine der leistungsstärksten Funktionen von C ++ / CLI muss die Möglichkeit sein, Ihren vorhandenen nativen C ++ - Code einfach in MSIL neu zu kompilieren. Natürlich kann es Schluckauf geben, aber für die meisten Anwendungen sollte es eine problemlose Übung sein.
Was die Eignung von C ++ / CLI anbelangt, denke ich, dass es strikt eine Sprache für die Interoperabilität mit C ++ bleiben wird. Wenn Sie eine völlig neue App schreiben, gibt es absolut keinen Grund, C ++ / CLI über, sagen wir, C # zu wählen. Wie gesagt, es ist etwas unpraktischer als das letztere.
Wir verwenden C ++ / CLI ausgiebig. Wir haben es verwendet, um eine alternde MFC-Anwendung in das .NET-Zeitalter zu ziehen, sodass wir jetzt die meisten neuen Funktionen in C # schreiben und diese mit dem alten MFC-Code mithilfe von C ++ / CLI integrieren können, indem wir native Klassen umhüllen und neue verwaltete Geschäftsobjekte schreiben . In unseren alten Assemblies schreiben wir immer noch neue Funktionen in C ++ / CLI.
Ich habe keine Erfahrung mit "verwaltetem C ++", aber C ++ / CLI ist eine Freude im Vergleich zu MFC und Visual C ++. Es hat eine viel sauberere Syntax als entweder verwaltetes C ++ oder Visual C ++ und wir hatten überhaupt keine Probleme damit, sogar jüngere Entwickler auf den neuesten Stand zu bringen.
Es gibt ein paar interessante Verhaltensweisen in C ++ / CLI. Wenn Sie beispielsweise ein natives Objekt in eine Methode einer verwalteten Klasse einfügen, wird ein nuanciertes Wrapper um das native Objekt (unsichtbar für den Entwickler) gelegt Der Anruf wird getätigt, aber das Shim ist für die Assistentin privat und kann daher nicht von außen angerufen werden. Es gibt Wege wie immer, aber es hat uns schon früh ein paar Mal erwischt.
Wir verwenden Visual Assist X für die Refactoring-Unterstützung (akzeptabel), MbUnit / Gallio für Unit-Tests der verwalteten Klassen und NMock oder RhinoMocks für unser Mocking-Framework.
Insgesamt würde ich sagen, dass die Sprache unser Produkt gerettet hat und uns ermöglicht, all die neuen aufregenden Dinge in der Entwicklungswelt zu nutzen. Wenn wir immer noch nur Visual C ++ / MFC verwenden würden, hätten wir Schwierigkeiten, Devs zu rekrutieren und bei der COTS-Wahl viel eingeschränkter zu sein als wir .Net.
C ++ / CLI war hervorragend, um die CLR in FreeSWITCH zu bringen . Viel einfacher als mit der Hosting-API oder mit Mono.
Das letzte Mal, bevor ich dies verwendete, war C ++ 2003 oder so. Ich erinnere mich, dass es ein bisschen schmerzte und nicht so nahtlos funktionierte.