Polemik: Killt Microsoft jetzt C++/CLI?

*rant*

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

mogel

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

phlox81

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

Jochen Kalmbach

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

audacia

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

Jochen Kalmbach

@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...

mogel

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

hustbaer

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.

theta

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

Tyrdal

Trotzdem stört IS auch bei Interop nicht.

hustbaer

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

hustbaer

Jochen Kalmbach schrieb:

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

Ich glaube rant will nur seinem Usernamen gerecht werden

phlox81

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.

hustbaer

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

phlox81

hustbaer schrieb:

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

Und events anlegen?
Oder meinst du jetzt MDA?

Zeus

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

hustbaer

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.

While*true***

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...

_matze

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...

hustbaer

Jochen Kalmbach schrieb:

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.

Und nicht nur bei den Einsteigern, sondern auch bei den "Profis". Weil die Einsteiger es einfach nicht wahr haben wollen, dass C++/CLI nicht die richtige Sprache für sie ist.

Vielleicht verstehen dann auch diverse Professoren dass C++/CLI nicht die richtige Sprache für ihren Kurs ist!
(Es sei denn es ist ein "advanced" Kurs wo es um .NET Interop geht)

Andrerseits ist es auch ganz gut dass es eine gratis Version von C++/CLI gibt. Sonst wären einige Open Source Projekte ziemlich angeschmiert.