Welche Vorteile bietet eine 100% verwaltete Entwicklung mit C ++ / CLI?

In C ++ / CLI können Sie Funktionen außerhalb von Klassen definieren, dies ist in C # nicht möglich. Aber ich weiß nicht, ob das ein Vorteil ist.

Ich würde denken, dass der größte Vorteil der Managed / Unmanaged Interop ist. Das Schreiben von rein verwaltetem C ++ / CLI würde (zumindest für mich), ohne mit C # oder anderen .Net-Sprachen zu kommunizieren, scheint den Punkt gänzlich zu verfehlen. Ja, du könntest das tun, aber warum würdest du das tun?

Wenn Sie reinen verwalteten Code schreiben, sollten Sie C # nicht verwenden. Vor allem (wie Nobugs sagten), wenn VS2010 die IntelliSense-Unterstützung für C ++ / CLI löscht. Auch in VS2008 ist das IntelliSense für C ++ / CLI nicht so gut das C # IntelliSense; Aus Sicht des Entwicklers ist es also einfacher, in C # zu arbeiten / zu erforschen / zu refactorisieren als in C ++ / CLI.

Wenn Sie einige der C ++ - Vorteile, die Sie auflisten, wie den Präprozessor, Stack-Semantik und Templates, dann warum nicht C ++ verwenden?

Seltsam, ich mag C ++ / CLI, aber Sie haben genau die Funktionen aufgelistet, die ich nicht mag. Meine Kritik:

• Okay. Aber die versehentliche Verwendung des Hutes ist ziemlich weit verbreitet, indem der Wert des Werttyps ohne Warnung in eine Box gebracht wird. Es gibt keine Möglichkeit, diesen Fehler zu diagnostizieren.
• Macht, die zu einem hohen Preis kommt, Templates, die Sie schreiben, sind in keiner anderen .NET-Sprache verwendbar. Wenn überhaupt, verschlechtert es das C ++ - Vorlagenexportproblem. Das völlige Versagen von STL / CLR ist es auch wert, darüber nachzudenken.
• Ähm, nein.
• Das war IMO ein schwerer Fehler. Es ist bereits schwierig, Probleme mit dem versehentlichen Verpacken zu vermeiden, wie in der ersten Kugel beschrieben. Stack-Semantik macht es für jeden startenden Programmierer schwer, dies zu beseitigen. Dies war eine Designentscheidung, um C ++ - Programmierer zu beschwichtigen, das ist in Ordnung, aber die using-Anweisung war eine bessere Lösung.
• Nicht sicher, wie es einfacher ist. Der Aufruf von GC.SuppressFinalize () ist automatisch, das ist alles. Es ist sehr selten, dass jemand einen Finalizer schreibt, aber Sie können nicht vermeiden, dass der automatisch generierte Code den Aufruf ausführt. Das ist ineffizient und eine Verletzung des Grundsatzes "Sie zahlen nicht für das, was Sie nicht verwenden". Hinzu kommt, dass beim Schreiben des Destruktors auch ein Standard-Finalizer automatisch generiert wird. Eine, die Sie nie verwenden würden und nicht verwendet werden möchten, wenn Sie den Destruktor vergessen oder weggelassen haben.

Nun, das ist vielleicht alles sehr subjektiv. Der Todesstoß kommt mit VS2010, es wird ohne IntelliSense-Unterstützung für C ++ / CLI ausgeliefert.

Wie andere hier, kann ich mir keine allgemeinen Fälle vorstellen, in denen ein klarer Vorteil existiert, so dass mein Denken sich situativen Vorteilen zuwandte - gibt es Fälle, in denen ein Vorteil in einem bestimmten Szenario besteht?

Vorteil: Nutzen Sie die C ++ - Fähigkeiten technischer Mitarbeiter in einem Rapid-Prototyping-Szenario.

Lassen Sie mich näher ausführen ...

Ich habe ziemlich viel mit Wissenschaftlern und (Nicht-Software-) Ingenieuren gearbeitet, die keine offiziell ausgebildeten Programmierer sind. Viele dieser Leute benutzen C ++ für die Entwicklung spezifischer Module, die High-End-Physik / Mathematik beinhalten. Wenn ein reines .NET-Modul in einem Rapid-Prototyping-Szenario benötigt wird und die Fähigkeiten des für das Modul verantwortlichen Wissenschaftlers / Ingenieurs C ++ sind, würde ich ihnen eine kleine Menge zusätzlicher Syntax beibringen ( public ref , ^ und% co_de) % und % ) und sie dazu bringen, ihr Modul als 100% gemanagte C ++ / CLI DLL zu programmieren.

Ich erkenne, dass es eine ganze Menge möglicher "Ja, aber ..." Antworten gibt, aber ich denke, dass die Nutzung der C ++ - Fähigkeiten des technischen Personals ein möglicher Vorteil von C ++ / CLI ist.

Sie können Enums und Delegates als generische Constraints in C ++ / CLI, aber nicht in C # haben.

Ссылка

Es gibt eine Bibliothek, um diese Einschränkungen in C # zu simulieren.

Ссылка

Seltsam, ich mag C ++ / CLI, aber Sie haben genau die Funktionen aufgelistet, die ich nicht mag. Meine Kritik:

• Okay. Aber die versehentliche Verwendung des Hutes ist ziemlich weit verbreitet, indem der Wert des Werttyps ohne Warnung in eine Box gebracht wird. Es gibt keine Möglichkeit, diesen Fehler zu diagnostizieren.
• Macht, die zu einem hohen Preis kommt, Templates, die Sie schreiben, sind in keiner anderen .NET-Sprache verwendbar. Wenn überhaupt, verschlechtert es das C ++ - Vorlagenexportproblem. Das völlige Versagen von STL / CLR ist es auch wert, darüber nachzudenken.
• Ähm, nein.
• Das war IMO ein schwerer Fehler. Es ist bereits schwierig, Probleme mit dem versehentlichen Verpacken zu vermeiden, wie in der ersten Kugel beschrieben. Stack-Semantik macht es für jeden startenden Programmierer schwer, dies zu beseitigen. Dies war eine Designentscheidung, um C ++ - Programmierer zu beschwichtigen, das ist in Ordnung, aber die using-Anweisung war eine bessere Lösung.
• Nicht sicher, wie es einfacher ist. Der Aufruf von GC.SuppressFinalize () ist automatisch, das ist alles. Es ist sehr selten, dass jemand einen Finalizer schreibt, aber Sie können nicht vermeiden, dass der automatisch generierte Code den Aufruf ausführt. Das ist ineffizient und eine Verletzung des Grundsatzes "Sie zahlen nicht für das, was Sie nicht verwenden". Hinzu kommt, dass beim Schreiben des Destruktors auch ein Standard-Finalizer automatisch generiert wird. Eine, die Sie nie verwenden würden und nicht verwendet werden möchten, wenn Sie den Destruktor vergessen oder weggelassen haben.

Nun, das ist vielleicht alles sehr subjektiv. Der Todesstoß kommt mit VS2010, es wird ohne IntelliSense-Unterstützung für C ++ / CLI ausgeliefert.

In C ++ / CLI können Sie Funktionen außerhalb von Klassen definieren, dies ist in C # nicht möglich. Aber ich weiß nicht, ob das ein Vorteil ist.

Ich würde denken, dass der größte Vorteil der Managed / Unmanaged Interop ist. Das Schreiben von rein verwaltetem C ++ / CLI würde (zumindest für mich), ohne mit C # oder anderen .Net-Sprachen zu kommunizieren, scheint den Punkt gänzlich zu verfehlen. Ja, du könntest das tun, aber warum würdest du das tun?

Wenn Sie reinen verwalteten Code schreiben, sollten Sie C # nicht verwenden. Vor allem (wie Nobugs sagten), wenn VS2010 die IntelliSense-Unterstützung für C ++ / CLI löscht. Auch in VS2008 ist das IntelliSense für C ++ / CLI nicht so gut das C # IntelliSense; Aus Sicht des Entwicklers ist es also einfacher, in C # zu arbeiten / zu erforschen / zu refactorisieren als in C ++ / CLI.

Wenn Sie einige der C ++ - Vorteile, die Sie auflisten, wie den Präprozessor, Stack-Semantik und Templates, dann warum nicht C ++ verwenden?

Wie andere hier, kann ich mir keine allgemeinen Fälle vorstellen, in denen ein klarer Vorteil existiert, so dass mein Denken sich situativen Vorteilen zuwandte - gibt es Fälle, in denen ein Vorteil in einem bestimmten Szenario besteht?

Vorteil: Nutzen Sie die C ++ - Fähigkeiten technischer Mitarbeiter in einem Rapid-Prototyping-Szenario.

Lassen Sie mich näher ausführen ...

Ich habe ziemlich viel mit Wissenschaftlern und (Nicht-Software-) Ingenieuren gearbeitet, die keine offiziell ausgebildeten Programmierer sind. Viele dieser Leute benutzen C ++ für die Entwicklung spezifischer Module, die High-End-Physik / Mathematik beinhalten. Wenn ein reines .NET-Modul in einem Rapid-Prototyping-Szenario benötigt wird und die Fähigkeiten des für das Modul verantwortlichen Wissenschaftlers / Ingenieurs C ++ sind, würde ich ihnen eine kleine Menge zusätzlicher Syntax beibringen ( %code% , %code% und% co_de) % und %code% ) und sie dazu bringen, ihr Modul als 100% gemanagte C ++ / CLI DLL zu programmieren.

Ich erkenne, dass es eine ganze Menge möglicher "Ja, aber ..." Antworten gibt, aber ich denke, dass die Nutzung der C ++ - Fähigkeiten des technischen Personals ein möglicher Vorteil von C ++ / CLI ist.

Sie können Enums und Delegates als generische Constraints in C ++ / CLI, aber nicht in C # haben.

Ссылка

Es gibt eine Bibliothek, um diese Einschränkungen in C # zu simulieren.

Ссылка

Man könnte sich die folgenden Anforderungen für ein hypothetisches Produkt vorstellen:

1. Schnelle Time-to-Market unter Windows
2. Eventuelle Bereitstellung auf Nicht-Windows-Plattformen
3. darf sich nicht auf Mono für Nicht-Windows
verlassen

In einem solchen Szenario würde die Verwendung von zB C # für 1 Sie auf 2 und 3 stemmen, ohne dass Sie neu geschrieben werden. So könnte man in C ++ / CLI entwickeln, passend mit Makros und Templat-Shenanigans, um so viel wie normales C ++ wie möglich zu sehen, um Reqt 1 zu treffen, dann um Reqt 2 zu erreichen, müsste man (a) die Makros und Template-Shenanigans neu implementieren auf Pukka C ++ zu mappen und (b) .NET-Framework-Klassen zu implementieren, die in Pukka C ++ verwendet werden. Beachten Sie, dass (a) und (b) in Zukunft einmal verwendet werden könnten.

Der offensichtlichste Einwand wäre: "Warum nicht das Ganze in nativem C ++ machen?"; Nun, vielleicht gibt es viele gute Sachen in der riesigen .NET-Klassenbibliothek, die Sie verwenden möchten, um so schnell wie möglich auf den Markt zu kommen.

Alles ein bisschen dürftig, gebe ich zu, also bezweifle ich sehr, dass das jemals gemacht wurde, aber es wäre eine lustige Sache, es auszuprobieren!