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

Polemik: Killt Microsoft jetzt C++/CLI?

  • 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

  • @phlox81:
    Also für mich ist RAD schon mehr als nur Fenster zusammenklicken.

    0
  • P

    hustbaer schrieb:

    @phlox81:
    Also für mich ist RAD schon mehr als nur Fenster zusammenklicken.

    Und events anlegen?
    Oder meinst du jetzt MDA?

    0
  • Z

    phlox81 schrieb:

    hustbaer schrieb:

    @phlox81:
    Also für mich ist RAD schon mehr als nur Fenster zusammenklicken.

    Und events anlegen?
    Oder meinst du jetzt MDA?

    Ich nehm mal die Antwort von hustbaer ab *gg* Die Möglichkeiten ganze Programmstrukturen und deren Eigenschafte über ein Oberfläche zu modifizieren macht RAD aus 😉

    0

  • phlox81 schrieb:

    hustbaer schrieb:

    @phlox81:
    Also für mich ist RAD schon mehr als nur Fenster zusammenklicken.

    Und events anlegen?
    Oder meinst du jetzt MDA?

    Ich meine dass noch mehr als nur GUI zu RAD gehört. Ein schönes Framework wo ich Datenbank-Anbindungen, Unterstützung für Standard-Formate (XML, aber z.B: auch Grafikformate, Soundformate), Netzwerk usw. beisammen habe gehört auch dazu. Und wenn geht alles schön über einen Editor bedienbar, wie es z.B. bei Visual Studio und C# der Fall ist.

    Ich will auch nicht behaupten dass es keine Solchen Tools für C++ gibt. Aber nicht jeder GUI Designer ist gleich RAD.

    0
  • W

    Nur mal ganz am Rande...

    Warum bringt Microsoft Press (und auch so ziemlich alle anderen Verlage) nur noch Bücher über C++/CLI raus, wenn es doch gar keine "Hauptsprache" ist.

    Dann doch lieber wieder mal ein paar Bücher über MFCNext...

    0
  • _

    Wenn du unbedingt C++/CLI in Verbindung mit dem VS2010 verwenden willst, schau dir mal den Visual Assist an (der ersetzt das blöde IntelliSense vollständig):

    http://www.wholetomato.com/default.asp

    Ob es schon eine Version für's neue VS gibt, weiß ich nicht. Schau bei Interesse einfach mal nach. Der VA-X kostet ein wenig, ist das Geld aber wirklich wert.

    EDIT: Klar, VA-X mit VS2010 geht natürlich schon...

    0
Anmelden zum Antworten