C++/CLI und WinForms macht keinen Sinn

Vielen Anfänger, welche C/C++ lernen wollen, suchen sich nach einer kostenlosen Entwicklungsumgebung und stossen dann früher oder später auf die Visual Studio 2008/2010 Express Edition.

Und ein Anfänger will natürlich gleich sichtbare Erfolge sehen und beginnt logischerweise gleich mit einer Fenster-Anwendung.

Leider enthält die VC2008/2010EE nur WinForms als graphische Oberfläche. Deshalb entwicklen die meisten dann nicht mit C/C++, sondern mit C++/CLI, was eine komplett andere Sprache ist und für die meisten nur zu Verwirrung führt.

Ich Rate jedem Anfänger davon ab VC 2008/2010 Express Edition für graphische Oberflächen zu verwenden, aus folgenden Gründen:

  • Der WinForms-Designer ist miserabel, da er die Implementierung von Methoden in der h-Datei vornimmt, was spätestens zu Problemen führt, wenn man mehr als ein Form hat und auf Methoden/Properties des anderen Forms zugreifen will (da man dann zyklische Abhängigkeiten in den h-Dateien hat, die man nur lösen kann, wenn man die Implementierung in die cpp-Datei verlegt)
  • Wenn man die Anwendung verteilen will, so muss man neben dem .NET-Framework auch die C-Runtime installieren; das muss man bei einer reinen .NET-Anwendung (z.B. C#) nicht
  • C++/CLI ist primär als InterOp Sprache zwischen .NET und native Code gedacht; das sieht man auch schon daran, dass seit VC2008 auch der Data-Wizward für C++/CLI entfernt wurde. Daraus ergibt sich gleich der nächste Punkt:
  • Der Data-Wizard wurde in VC 2008 entfernt um auch deutlich zu machen, dass der Focus auf native-managed InterOp liegt
  • Ca. 99% aller Beispiele im Internet sind mit C#; man findet fast keine Beispiele in C++/CLI
  • C++/CLI ist eine eigene Sprache und hat mit (ISO) C/C++ nichts zu tun; und das ganze zu mischen ist meistens noch viel sinnfreier, es sei denn, man weiss was man tut (was zu 99% nicht der Fall ist; zumindest in den Fragen, die ich aus den Foren entnehme)
  • C++/CLI wird oft als “Erweiterung” von C/C++ gesehen. Diese Sicht ist aber komplett falsch! Ganz einfacher Beweis: Versuch in einen STL-Vector ein CLR Objekt reinzustopfen (z.B. std::vector). Wenn es gehen würde, dann könnte man C++/CLI als Erweiterung sehen. Es geht aber nicht. Deshalb sind es zwei komplett getrennte Welten!
  • In VS 2010 wird es für C++/CLI Projekte kein Intellisense geben; das deutet auch stark darauf hin, dass es nicht als primäre Sprache für .NET geeignet ist
  • VC 2012 enthält keine Projekt-Templates mehr für WinForms!!!! Siehe: http://blog.kalmbach-software.de/de/2012/08/23/breaking-changes-in-vc2012/

Meine Empfehlung für Anfäger:
Wenn Ihr unbedingt graphische Oberflächen machen wollt, dann nehmt lieber C# (gibt es auch als Express Edition).

Meine Empfehlung für Microsoft:
Wenn Ihr auch mit VC++ Anfänger erreichen wollt, dann liefert bitte die MFC in der Express-Edition mit; oder bindet von mir aus wxWidgets ein 😉

12 thoughts on “C++/CLI und WinForms macht keinen Sinn

  1. cf

    Guter Artikel.
    Das MFC nicht in der Express-Edition ist, finde ich auch ärgerlich.

  2. Anfaenger

    Endlich einmal Jemand mit einer auch für Anfänger nachvollziehbaren Aussage!

  3. Georgius Stolte

    Ich konnte es nicht glauben, aber es ist wirklich so gekommen: Microsoft hat auch in der Release Version von VS 2010 die Intellisense Unterstützung für C++/CLI entfernt.

    Auch wenn diese schon in der 2008er Version nicht besonders gut funktioniert hat, war sie immer noch eine große Hilfe.

    Offenbar wollte man seitens Microsoft Programmier-Einsteiger dazu motivieren, sich gleich mit der .net-Technologie zu beschäftigen, da es in den Express Editionen nur die Möglichkeit gibt, graphische Benutzeroberflächen mithilfe von Windows-Forms zu erzeugen.

    Jetzt hat man den Eindruck, dass durch den gezielten Einbau von Fiesheiten die Leute dazu gebracht werden sollen, zwecks .net-Programmierung völlig zu C# oder VB.net zu wechseln.

    Und wieso werden Express-User (z.B. bei der 2008) mit Einschränkungen beim Syntax-Highlighting ( {…} … arghn!) bestraft, wo schon vor 10 Jahren kostenfreie IDEs diesbezüglich vollständige Tipphilfen anboten?

    Mein Rat an Microsoft:

    Entweder Ihr gebt Visual C++ 2010 Express ein Stück Brauchbarkeit zurück, und schiebt das Intellisense per Service Pack nach, oder man stellt zumindest die Möglichkeit eines rudimentären GUI-Designs per MFC zur Verfügung, oder die Express Edition wird ganz eingestampft.
    So ist sie jedenfalls in Bezug auf die Entwicklung von .net-GUI Programmen weitgehend sinnfrei.

    Mein Rat an Anfänger:

    C++/CLI hat sowieso mehr Ähnlichkeit mit C# oder Java als mit “richtigem” C++. Für die Entwicklung von .net Programmen nehmt besser C#. Für ISO-C++ gehen auch andere IDEs wie Code::Blocks, Eclipse, NetBeans, openWatcom und bastelt Eure Oberflächen mit Qt oder
    wxWidgets zusammen. Oder nehmt etwas Geld in die Hand und kauft Euch Visual Studio…
    aber, ja richtig, ich vergaß: Die Standard Edition gibts ja garnicht mehr. So ein Zufall.
    Und für das kleinste noch verfügbare Visual Studio 2010 (die Professional Edition) legt man mal eben sowas um die 700 Euro hin…. Microsoft ts ts ts… na besten Dank.

    Der Verdacht liegt jedenfalls nahe, daß Microsoft C++/CLI sterben lassen will. Darin investierte Zeit könnte langfristig verschwendet sein.

  4. Radium

    Naja, oder es liegt einfach daran, dass die Leute, die mit C++ anfangen sich erstmal ein Buch kaufen sollten anstatt gleich loszuprogrammieren. Ich steige gerade von VB zu C++ um und ich finde es auch etwas umständlich. Was man aber nicht vergessen darf ist, dass C++ nicht so beschränkt ist wie C++. Da kann man auch einer ganz anderen Ebene programmieren, man muß sich damit nur beschäftigen. C# ist da sicher ein netter Ansatz von Microsoft, aber auch die wissen, dass C# bei weitem nicht so Leistungsfähig ist!
    Ihr könnt übrigens VC++ auch in der Express wie normales C++ verwenden. Im Prinzip braucht ihr nur die Windows Forms als GUI und den Rest verwendet ihr einfach nicht. Und der Zugriff auf die GUI eines anderen Form kann man auch anders lösen, als in die cpp zu kopieren. Dafür gibt es Gültigkeitsbereiche, die man einfach nur setzen muß. Manschmal hilft auch einfach nur ein #include und #pragma once verhindert das Mehrfachladen der Header!

  5. HalliGalli

    @Radium Richtig, C++ ist nicht so “beschränkt” wie z.B. VB (nicht VB.Net!) aber es ist auch deutlich Fehleranfälliger und die Entwicklung mit C++ dauert in der Regel auch deutlich länger als mit VB.Net/C#.

    Und wieso soll C# “bei weitem” nicht so leistungsfähig wie C++ sein?. Kannst du da bitte mal ein konkretes Beispiel posten? Ich würde sagen, es eher andersrum ist! Oder kann C++ Sachen wie z.B. Linq, Typinferenz oder Lambaausdrücke? Der aktuelle Standard kann es zumindest nicht.

    Wenn Ihr schon managed Code programmiert, dann tut euch selbst einen gefallen und nehmt C#/VB.Net. Die Synatx ist wesentlich angenehmer als die von managed C++.

    Versteh mich bitte nicht falsch. C++ hat durchaus seine daseinsberechtigung. Aber das meiste lässt sich heute mit managed Code (.net, Java etc.) deutlich schneller, sicherer und kostengünstiger implementieren als mit C++.

    Der Unterschied in der Performance ist zwar noch Vorhanden, ist aber so gering geworden, dass er in der Praxis kaum mehr spürbar ist (wobei es allerdings auch Ausnahmen gibt. Hängt vom Applikationstypen ab).

  6. Michael

    Guter Artikel! Habe mir jahrelang mit c++/cli einen “abgekrampft” und jetzt beseitigt Microsoft so langsam die “Missgeburt”. Qt ist eine echte Alternative für C++ Programmierer und arbeitet perfekt mit der C-Sprache zusammen auch das neue QML.

  7. Toastbrot

    @author:
    Tausend Dank!
    Wollte heute mit GUI Programmierung in C++ anfangen.
    Endlich mal ein Artikel, der mir verständlich erklärt, warum nichts so klappt, wie ich es mir vorgestellt habe!

  8. Tim

    Der Post sollte eher “C++ Anfänger sollten nicht mit C++/CLI starten” heißen, dann könnte ich dem evtl. auch zustimmen ! Sonst bin ich ziemlich erschrocken mit wieviel unqualifizierten Aussagen hier aufgewartet wird.

    Über den Punkt “man muss die C-Runtime” ausliefern habe ich am meisten gelacht. Die C-Runtime auszuliefern ist ein Kinderspiel ! Man packt ein paar DLLs zusammen und das war es ! Das geht bei .Net schon gar nicht, denn das muss man installieren. Was ist denn da jetzt umständlicher ? Doch wohl eher letzters.
    Die Aussage, dass C++/CLI eine eigene Sprache ist halte ich für Diskussionswürdig und weshalb sollte man denn ein CLR Object in einen vector stecken ? Das .Net-Framework hat eine breite Anzahl von Klassen und Libraries unter anderem Collections, die einem hier weiterhelfen.
    Außerdem gleicht der Versuch irgendwie einem Versuch mit ANSI C Interop mit C++ Klassen anzustellen. Rückwärtskompatibilität ist nunmal nicht immer möglich oder gewollt bei Neuentwicklungen.

    Nicht falsch verstehen ! Ich kann mich durchaus Aussagen wie:
    – C++/CLI ist nichts für Programmier/Sprach-Anfänger
    – C++/CLI ist vorwiegend für InterOp geeignet
    – Bei C++/CLI hätte Microsoft einen besseren Job vor allem bei der Dokumentation tun können
    anschließen, aber wenn man schon in dieses “Horn” bläßt und Anfänger adressiert dann sollte man auch etwas mehr bei den Fakten bleiben.

  9. Pingback: Jochen Kalmbach’s Blog » Blog Archive » Breaking changes in VC2012

  10. Matthias

    Hallo Jochen,

    mich interessiert mal, was zukünftig für Windows – Programmentwicklung als relevantes Sprachwerkzeug in Frage kommen könnte. Ist damit zu rechnen, dass auch weiterhin C/C++ eine wichtige Rolle spielt und mit den M.F.C. Programme erstellen werden können, oder geht der Trend eher in die Richtung von common- language- infrastructure – basierter Programmierung mit Scriptsprachen wie C# , VB oder JAVA ?

  11. jkalmbach Post author

    Das ist eine sehr schwierige Frage… aktuell kann glaube ich niemand ganz sicher sagen, wohin es geht. Wenn man MS glauebn mag, so geht die Entwicklung hin zu Apps… dies ist zwar auch in C++ mögllich, wird aber dort wohl nur in Randbereichen von nöten sein. In C# lässt sich dies oft einfacher realisieren. Mit CLI hat dies nichts zu tun, wenn dann mit WinRT.
    Im Folgenden Link sieht man ein wenig, wohin es gehen könnte:
    http://blogs.msdn.com/b/win8devsupport/archive/2012/11/14/porting-ios-apps-to-windows-8-1-introducing-windows-8-platform-to-ios-app-developers.aspx

  12. Peter Meier

    Nun ja, Microsoft macht eine Reihe von Entwicklungen durch:
    native Win32 API (für C Programme)
    MFC (für C++ Programme)
    DotNET (für C+ Programme, C++ nur managed code)
    UWP (WindowsPhone Apps)
    Bei jedem Schritt wird der vorherige Stand zerstört, in der Hilfe und Doku kaputt gemacht, und verschwiegen und die neue Variante als die einzig mögliche und sinnvolle angespriesen.
    Diese Politik von Microsoft führt zur aktuellen Situation, daß man sagen muss. Lasst die Finger von allem was Microsoft propagiert. Der Win32 API Standard ist der einzige, der auf Dauer funktioniert. Alles andere ist kurzlebig und mit gigantischem Overhead verbunden. Wer sich die Mühe gibt, die neuen Plattformen zu erlernen, sitzt schon nach kurzer Zeit wieder auf dem trockenen, siehe Windows Phone. Welches Phone ? Schneller tot als daß man überhaupt angefangen hätte. DotNET ist für C++ nicht zu gebrauchen, weil es für C# genaut ist als Alternative zu Java. Dann lieber gleich java lernen, damit kann man zumindest Android Apps schreiben. Und wer C++ macht, und erkennt daß MFC schon jahrzehnte nicht geplfegt ist und als eher tot gilt, sollte auf das Win32 API zurückgreifen.

Comments are closed.