Ich habe irgendwo gehört, dass Microsoft seine Bemühungen auf C# anstatt C++ für die .NET-Plattform konzentrieren wird. Ich kann sehen, dass dies wahr ist, weil der GUI-Designer für C#, aber nicht für C++ verfügbar war.Stirbt C++ .NET?
Also ich würde gerne wissen, ob C++ in .NET stirbt und ob es in Zukunft weiterhin die Nummer 2 von C# sein wird.
Wenn Sie in der Anwendungsentwicklung auf das .NET-Framework abzielen, ist C++/CLI im Vergleich zu C# ein Bürger zweiter Klasse. C# wurde speziell als die Sprache für .NET-Framework entworfen, während C++/CLI-Erweiterung gibt es jetzt, damit Entwickler nativen und verwalteten Code zu überbrücken.
Allerdings nicht verwechseln C++ mit C++/CLI (C++ .NET ist das gleiche ...). C++ ist in Bereichen wie dem Kernel, Spielen, Hochleistungs- und Server-Apps (z. B. SQL-Server) lebendig und gut, von denen sich alle kaum ändern werden. Auf der anderen Seite werden die meisten .NET 'GUI Stuff' nicht C++ verwenden.
Ich wusste nicht, dass Sie mit nativem C++ auf das Framework zugreifen können (ist das der Grund, warum Sie sagen, dass es dasselbe ist wie C++ .NET?). – Unknown
Er sagt "C++ CLR" ist die gleiche Sache wie "C++ .NET" – sharkin
Sie müssen dem C++ - Compiler das/clr-Flag geben, wenn Sie verwalteten und systemeigenen Code in derselben Assembly verwenden möchten. Das Hinzufügen dieses Flags bewirkt, dass der Compiler der Assembly .NET Framework-Metadaten hinzufügt. Sie können auch/clr: safe und/clr: pure flags verwenden, um MSIL-only .NET-Assemblies zu generieren. In diesem Fall sind C# und C++ gleich (dito für VB.NET, J # usw.). – Serguei
Verwaltetes C++ war nie wirklich das, was MS dachte. C# könnte (fast) dasselbe tun, mit einer viel intuitiveren und benutzerfreundlicheren Syntax.
Abgesehen davon wird C++/CLI für eine lange Zeit nicht unterstützt, da es eine einfache Möglichkeit ist, Interop zwischen .NET Assemblies und nativen C++ Assemblies zu erstellen. Das ist ungefähr alles, für das es verwendet wird (ich bin mir sicher, es gibt 0,001% der C++/CLI-Entwickler da draußen, die anderer Meinung sind: P).
Also sagst du, dass Sie nicht Interop zwischen C# und nativem C++ tun können? Ich dachte, das p/invoke-Ding ist in C# – Unknown
@Unknown völlig unbrauchbar. Er sagt nicht, dass Sie nicht können, er sagt "C++/CLI ist der einfache Weg". Ich weiß nicht, ob ich dem zustimmen würde, denn nichts in C++/CLI sieht für mich einfach aus. –
C++/CLI ist überraschend einfach ... zumindest, im Vergleich zu dem Umschreiben der SDK-Header von Grund auf notwendig, P/Invoke zu verwenden. – Shog9
C++/CLI ist nur die Art, wie Microsoft native C++ - Entwickler zu .NET anzieht. Es war wie eine Zwischenschicht zwischen nativem C++ und C#, aber ich bin mir ziemlich sicher, dass Entwickler lieber natives C++ oder C# wählen.
Microsoft wird C++/CLI zumindest in naher Zukunft nicht sterben lassen, ohne Community-Unterstützung wird C++/CLI jedoch nicht wachsen können.
In dieser Generation bedeutet nicht wachsen fast tot.
Auf der anderen Seite sieht es für mich so aus, als ob die Programmierwelt viel gereift ist und ich erwarte im nächsten Jahrzehnt nicht viel Wachstum. Es gibt keinen Grund, warum eine signifikante Technologie auf einer relativ konstanten Nutzerbasis nicht lange überleben kann. –
Ich fürchte es ist.
Der Grund dafür ist nicht C# (was nichts Besonderes bringt und obwohl es eine neue Sprache ist, führt es nicht in neuen Sprachfunktionen, sondern kopiert nur die Eigenschaften anderer - Generika).
Es liegt hauptsächlich daran, dass der erste Versuch von MS, C++ für die .NET-Plattform - Managed C++ - zu aktivieren, ein Desaster war.
Danach mieteten sie Herb Sutter, C++ - Guru, die fantastische Arbeit bei der Entwicklung von Managed C++ - Ersatz called C++/CLI gemacht. Warum und wie viel C++/CLI-Design dem Managed C++ - Design überlegen ist, können Sie durch Lesen von von Herb herausfinden.
Übrigens hat Herb den vc-Compiler zu einem der besten standardkonformen Compiler für Windows gemacht, nachdem er jahrelang der schlechteste Standardkonform ist.
Ich denke, die Managed Extensions waren ziemlich gut, besser als C++/CLI. Leider hat es lustige Erweiterungen hinzugefügt und die Leute haben das nicht gemocht, also haben sie verschiedene Erweiterungen eingefügt (seufzen) und die Fähigkeit zerstört, verwaltete Ressourcen "nativ" zu verbrauchen (dh auf dem nativen Heap, ohne^überall hinzusetzen). Herb ist gut, aber ich glaube nicht, dass er mit C++/CLI so gute Arbeit geleistet hat. – gbjbaanb
Haben Sie "A Design Rationale für C++/CLI" gelesen? Von dem, was Sie sagen, ich denke, Sie haben nicht ... –
Äh, gbjbaanb, wenn ich mich nicht irre, verwaltete Ressourcen waren nie auf dem nativen Heap. Der Operator^wurde hinzugefügt, um eine Unterscheidung zwischen verwalteten und nicht verwalteten Objekten zu erstellen, da sich zuvor verwaltete Objekte noch auf dem verwalteten Heap befanden. Es gab jedoch keine Syntax, um dies anzuzeigen. –
Ich denke nicht, dass es notwendigerweise weggeht, aber der Grund für die Verwendung kommt fast immer darauf an, ob Sie die Leistungsvorteile benötigen, die damit verbunden sind. Wenn C# bei 90% der Effizienz von C++ dasselbe tun kann, ist das nicht wirklich gut genug?
Nein. Es wurde tot geboren.Es wurde immer als ein Citezen zweiter Klasse ohne Vitalitätsplan behandelt.
Bedeutendes Leben, dank C++/CX, dessen Syntax * sehr * ähnlich ist. Sie haben sogar IntelliSense-Unterstützung hinzugefügt. –