4. Polemik: Killt Microsoft jetzt C++/CLI?

Polemik: Killt Microsoft jetzt C++/CLI?

  • *

    Hallo Community,

    Ich habe dieses Wochenende einige schlimme Sachen bemerkt im bezug auf Microsofts Umgang mit C++/CLI und wie man dort mit den Programmierern umherspringt. Es ist unter aller Sau... Achtung: Polemik ⚠

    Zuerst wollte ich unter Visual Studio 2008 mit C++/CLI etwas .NET 3.5 programmieren, aber man erhält druchs Band einen reproduzierbaren Absturz, wenn man die System.Core.dll einbindet und irgendwelche String-Methoden ( System::String::Format ...) benutzen will! Dazu gibt es diverse Beschwerden, die aber nicht ernst genommen werden. Einen Hotfix wird es nicht geben. Nicht so schlimm dachte ich mir, kommt ja sowieso bald Visual Studio 2010 wo das dann sicherlich alles funktioniert.

    Als nächstes lade ich mir die Beta 2 von Visual Studio 2010 Ultimate herunter; dort wurde das Problem behoben und das Programm kompiliert. Als ich losprogrammieren will merke ich etwas viel schlimmeres: für C++/CLI wurde in Visual Studio 2010 das IntelliSense komplett gestrichen! 😡

    Habib Heydarian's Blog @ Microsoft schrieb:

    In Visual Studio 2010, when you try to use IntelliSense for in a C++/CLI project, you'll see the following message in the status bar: Intellisense: 'Unavailable for C++/CLI'.

    I fully expect this feature to come back in a future release. You can read more about this on the Rebuilding Intellisense blog post which was written by members of the Visual C++ team. Just to make it super clear, IntelliSense is fully supported for native C/C++. Where it's not supported is Managed C++ (oldSyntax) and C++/CLI.

    Boris Jabes, Visual C++ Team Blog schrieb:

    While the lack of Intellisense for C++/CLI is unfortunate, we expect that it only represents a small portion of your source code that you don't need to edit nearly as often as the native code. Indeed, the only scenario we don't recommend is to use C++/CLI as a first-class .NET language. Instead, we think it's the ideal solution for interop.

    Microsoft on 11/6/2009 at 4:20 PM schrieb:

    We do plan on implementing C++/CLI intellisense in the future; however, I can't comment as to whether it will be in the service pack or the next release.

    Thanks,
    Mark Roberts
    Visual C++ Team

    What the ****, Microsoft? Das Intellisense für C++/CLI gibt es vielleicht in der nächsten Version wieder? Es ist mir egal, ob das neue Visual Studio einen Quad Core braucht oder 7 GB RAM, aber einen derartigen Rückschritt kann ich nicht hinnehmen. Es ist klar, dass das Intellisense von Visual Studio 2008 in C++/CLI nicht gerade sehr stabil funktionierte, aber dieses als Konsequenz daraus ganz aus der neuen Version zu streichen während mit F# eine neue nutzlose Sprache in Visual Studio einfliesst ist ein Schlag ins Gesicht aller, welche C++/CLI dazu nutzen wollen, ihre alten Applikation mühsam nach .NET / WPF zu portieren. Ich bin in einigen Projekte auf C++/CLI angewiesen, verwende es zum Teil in Kombination mit boost und wollte jetzt die ersten Elemente von C++0x einfliessen lassen, aber so geht das nicht schön 👎

    Ich weiss nicht, was ich damit anfangen soll; ich bin schlicht entsetzt. Man kann theoretisch mittels connect.microsoft.com Microsoft ein Feedback zu diesem Thema geben, aber schlussendlich bleibt es deren Entscheidung. Das wollte ich nur mal loswerden. Vielen Dank für eure Zeit.

    MfG

    0
  • A

    > Es ist mir egal, ob das neue Visual Studio einen Quad Core braucht oder 7 GB RAM,

    Ja, zum %&§!*%!! Wieso müssen die jetzt auch noch für VS WPF benutzen? So ein langsames VS hatte ich noch nie. Immerhin, in Beta 2 haben die es hinbekommen, den Text wieder scharf zu rendern. 🙄

    0
  • *

    Ad aCTa schrieb:

    > Es ist mir egal, ob das neue Visual Studio einen Quad Core braucht oder 7 GB RAM,

    Ja, zum %&§!*%!! Wieso müssen die jetzt auch noch für VS WPF benutzen? So ein langsames VS hatte ich noch nie. Immerhin, in Beta 2 haben die es hinbekommen, den Text wieder scharf zu rendern. 🙄

    Nun, ich habe kein Problem, wenn die Anforderungen steigen, aber dann sollen sie wenigstens die WPF richtig benutzen und dem Auge etwas bieten. Wenn sie aber Visual Studio 2010 in der WPF so implementieren, dass es optisch mit Visual Studio 2008 vergleichbar ist, dann können sie sich das gleich sparen und die Anforderungen tief halten. So wie es jetzt ist, bringt das einfach nur Ärger 👎

    Ein weiterer Punkt der mich stört: External Dependencies im Solution Explorer unter C++ und jetzt auch unter C++/CLI sind zurück. Dieser Schwachsinn, welcher zuletzt mit Visual Studio 6 bindet dir einen Ordner ein, welchen du weder deaktivieren, noch verwenden kannst; wo irgendwelche verwendeten Dateien aufgelistet werden.

    So geht das einfach nicht. Visual Studio 2005 und insbesondere auch 2008 waren IMHO zwei der besten Produkte, welche Microsoft jemals rausgebracht hat, aber die 2010er Version ist in dieser Form unbrauchbar 💡

    0
  • R

    Naja die Performace von VS2010 ist wirklich schlecht und es verbruacht bei mir(x64) manchmal 1GB Ram, aber soweit ich weiß hat sich das schon kurz nach der Beta 2 deutlich verbessert:
    http://blogs.msdn.com/bharry/archive/2010/01/24/state-of-vs-2010-performance.aspx

    0
  • M

    Dein Beitrag und Dein Titel beisen sich etwas ... blos weil IS nicht funktioniert heißt das noch lange nicht das C++/CLI eingedampft wird

    0
  • ?

    C++/CLI wird von MS schon Stiefmütterlich behandelt.

    Ab der Version 2008 wird die direkte Datenbankanbindung für C++/CLI nicht mehr unterstützt. Nun noch die IS.

    Der Sprecher von Microsoft ist mir bei der Veranstaltung für Visual Studio 2010 in Hamburg ständig ausgewichen, mir wurde gesagt, dass man sich mehr auf C# oder VB konzentrieren sollte.

    C++/CLI ist eine Beule am Fuß für MS und den Sinn von F# habe ich auch noch nicht erkannt.

    Und Java# ist auch weg vom Markt und C++/CLI wird sicherlich folgen, früher oder später.

    0
  • J

    Meine Meinung ist:
    Seit VS2008 wurde eine Kehrtwende in der C++/CLI-Politik betriebe. Bis VS2005 war es eine 1st-Class-.NET Sprache. Abs seit VS2008 wird C++/CLI *nur noch* für InterOp empfohlen. Da man schon daran gesehen, dass sie den DataWizard entfernt haben. Auch wurde in den WinForms-Designer nichts mehr investiert (immer noch der gleiche wie in VS2002).
    Seit VS2008 wird wieder mehr "Wert" auf *native* Code gelegt. Man sieht es an TR1 und HPC und sonstige Paralell-Computing-Investitionen, die massiv zugenommen haben (auch im OS 😉 ).
    Dass die Intellisense in VS2010 rausfliegt haben sie schon in der vorletzten TechEd in Barcelona gesagt... das System wurde ja komplett umgestellt... und für C++/CLI wäre es nochmals etwas ganz anderes gewesen..
    Dafür ist jetzt aber auch in native C++ das Intellisense besser...

    Mein Fazit: In der Exress-Edition sollte man C++/CLI streichen!!! Das führt auch bei den meisten Einsteigern zu massiven Problemen und unnötigen Frustrationen. Mir wäre es lieber, wenn in der Express-Edition die MFC mit dabei wäre... das wäre zumindest ein "richtiger" Fokus auf native Code.

    C++/CLI sollte man wirklich nur für extensive InterOp verwenden...

    Immerhin haben Sie ja in VS2010 die Manifest-Hölle der CRT/MFC wieder entfernt 😉

    0
  • *

    Ich habe immer gehofft, dass C++/CLI für Microsoft das bleiben wird, als was es ursprünglich konzipiert wurde: Das grösste Geschütz im Visual Studio, welches alle Möglichkeiten der Platformen .NET/x86-32/x86-64/etc. in einer einzigen Sprache mehr oder weniger komfortabel Ansprechen kann zwecks InterOp, aber gleichzeitig auch eine first class .NET language ist. Dass dabei Dinge wie LINQ und andere Erweiterungen wegfallen ist nicht so tragisch; das sind reine syntaktische Zückerchen. LINQ lässt sich über die entsprechenden Assemblys auch benutzen. Aber dass C++/CLI auf diese offensichtliche Art degradiert wird ist nicht mehr vertretbar.

    Ich finde es sehr schade, dass der Fokus der Sprache jetzt scheinbar nur noch auf extensiven InterOp liegt. Ganz am Anfang, mit Managed Extensions for C++ war dies klar, aber danach mit C++/CLI konnte man Programme schreiben, welche für einen erfahreneren Programmierer klarer sind als mit C# (C++ zwingt den Programmierer z.B., explizit zwischen Referenzen und eigentlichen Werten zu differenzieren). Ich will wieder den first class Support von Microsoft 😞

    0
  • M

    "schön" ... werde dann wohl doch komplett auf Java umsteigen 😡

    0
  • P

    Ist doch schön, das dieses kranke Konstrukt endlich in die Schranken gewiesen wird.
    Imho gibts dafür sowieso keine Verwendung, .net hat als Hauptsprache sowieso C#, und wer ernsthaft in C++ entwickelt, muss sowieso auf den CLI Part verzichten, für Plattformunabhängigkeit ist das sowieso unverzichtbar.

    Also Standard C++/STL + boost weiterhin fürs Backend und für die GUI gibts eine breite Auswahl von MFC über wxWidgets bishin zu Qt oder GTK. 👍

    phlox

    0
  • J

    @phlox81: Sehe ich auch so...
    @/rant/: Ich glaubt Du musst Dich damit abfinden und auf C# umsteigen 😉

    0
  • A

    Na, das war ja ein kurzes Vergnügen :p
    Wenn das so weitergeht, ist C++Builder das einzige verbleibende C++-RAD-Tool.

    0
  • J

    @audacia: Das hast Du dann aber ganz falsch verstanden...
    MS VC++ ist super in *native* Code. Ich habe es noch nie für WinForms-Zeugs verwendet...

    Also MS VC++ blibt in native-Code super und hat auch massiv in den native Designer (Resourcen) investiert! U.a. ist in VS2010 auch wieder der Class-Wizard drin!

    Aber für .NET sollte man lieber C# nehmen...

    0
  • M

    Jochen Kalmbach schrieb:

    Aber für .NET sollte man lieber C# nehmen...

    solange wie ich unter C# (VB.NET) solche Spielchen machen muss um die API einzubinden

    [DllImport("user32.dll")]
public static extern int LoadIcon(int hinst, String name);
[DllImport("user32.dll")]
public static extern int DestroyIcon(int hIcon);

    macht das keinen Sinn ... wenn ich C++/CLI nehme hat das schon seinen Grund - mit den Problemen die sich daraus ergeben (nativ/managed) muss ich wohl leben bzw. sie vernüftig lösen

    das die in die Express Variante wirklich CLR packen statt MFC ist definitiv eine Fehlentscheidung ... und wahrscheinlich weil sich soviele Beschwert haben das C++/CLI zu kompliziert ist (gegenüber C++) macht MS jetzt ein Rückzug

    hand, mogel

    0

  • Ich habe immer gehofft, dass C++/CLI für Microsoft das bleiben wird, als was es ursprünglich konzipiert wurde: Das grösste Geschütz im Visual Studio, welches alle Möglichkeiten der Platformen .NET/x86-32/x86-64/etc. in einer einzigen Sprache mehr oder weniger komfortabel Ansprechen kann zwecks InterOp, aber gleichzeitig auch eine first class .NET language ist.

    C++/CLI war nie als das gedacht.

    Ich würde auch keinem Empfehlen C++/CLI für irgend ein Projekt zu verwenden, ausgenommen für Interop Sachen.

    0
  • T

    hustbaer schrieb:

    Ich habe immer gehofft, dass C++/CLI für Microsoft das bleiben wird, als was es ursprünglich konzipiert wurde: Das grösste Geschütz im Visual Studio, welches alle Möglichkeiten der Platformen .NET/x86-32/x86-64/etc. in einer einzigen Sprache mehr oder weniger komfortabel Ansprechen kann zwecks InterOp, aber gleichzeitig auch eine first class .NET language ist.

    C++/CLI war nie als das gedacht.

    Ich würde auch keinem Empfehlen C++/CLI für irgend ein Projekt zu verwenden, ausgenommen für Interop Sachen.

    100% Ack.

    Simon

    0
  • T

    Trotzdem stört IS auch bei Interop nicht.

    0

  • Tyrdal schrieb:

    Trotzdem stört IS auch bei Interop nicht.

    Natürlich nicht!

    Ich wollte nur darauf hinweisen, dass C++/CLI nicht als "Haupt-Sprache" für irgendwelche Projekte gedacht ist/war, und auch nicht als solche eingesetzt werden sollte.
    Dadurch ist es IMO viel leichter zu verschmerzen, dass IS nicht geht.

    Man kann (und sollte) ja seine C++/CLI Projekte auch in einen reinen C++ Teil (.lib/.dll) aufsplitten, und nur das was wirklich nötig ist als C++/CLI implementieren. Dann nervt es noch weniger wenn es kein IS für den (nunmehr kleinen) /CLI Teil gibt.

    Ansonsten: Visual Assist X 🙂

    0

  • Jochen Kalmbach schrieb:

    @/rant/: Ich glaubt Du musst Dich damit abfinden und auf C# umsteigen 😉

    Ich glaube rant will nur seinem Usernamen gerecht werden 😉

    0
  • P

    audacia schrieb:

    Na, das war ja ein kurzes Vergnügen :p
    Wenn das so weitergeht, ist C++Builder das einzige verbleibende C++-RAD-Tool.

    Das ist aber sowas von falsch.
    Für wxWidgets gibts dutzende, und für Qt gibts den Designer und Qt Creator bringt sogar seinen eigenen mit.

    0
Anmelden zum Antworten