War schon "supermodernes" MFC. Gegen
VCL hat es aber eher noch Assemblercode ausgeschaut ...
Das bringt mir die Gelegenheit wieder zum eigentlichen Thema des Threads zurückzukommen.
In gewisser Weise haben
VCL und MFC ja derzeit etwas gemeinsam. Beide sind irgendwie am Ende des Weges angekommen und werden von ihren Herstellern etwas stiefmütterlich behandelt.
Kein Zweifel, dass die
VCL eine der besten Lösungen für klassische Windows Desktop Anwendungen ist. Höchstens Qt kann da mithalten. MS hat da im nativen Bereich im Moment nix, allerdings haben sie für Win8 Apps gezeigt, dass sie mit C++11 ein natives Gegenstück zu C# haben, siehe die Beispiele oben. Wohlmöglich kommt das demnächst auch für Desktop Anwendungen, dann werden die Karten neu gemischt.
Die Liebe von Embarcadero gehört derzeit ganz klar dem "brennenden Affen", sowohl für Delphi als auch dem C++ Builder. Wenn ich mir das so ansehe, im Licht der "Argumente" des Threaderstellers, wie
Zitat:
- Sehr einfache plattformübergreifende GUI-Erstellung
- Wartbarkeit: Wesentlich klarerer und damit wartbarer Code als mit C/C++
- Stabile Plattformbasis, also nachhaltige Investition
- usw.
dann wird mir unwohl.
Andere Dinge sind relativ
Zitat:
Ein kürzlich von Delphi1 geschriebenes größeres Projekt liess sich erstaunlich einfach und schnell auf Delphi 2010 hochziehen: Nachhaltigkeit.
Mit dem OpenSource-Projekt OWLnext laufen Projekte aus Borland C++ 4 von 1994 auf Visual Studio 2012 ...
Zitat:
Keine Garbage-Collection notwendig, also auch keine Zwangs-Pause des Programmbenutzers üblicherweise genau dann wenn etwas schnell gehen muss.
Ich glaube die C++11 Beispiele oben zeigen sehr gut, dass andere Sprachen deterministische Resourcenbereinigung auch sehr gut hinkriegen. Nebenbei bemerkt, machen aktuelle .net Frameworks keine Stop The World Garbage Collection mehr.
In diesem Punkt steckt etwas wahres
Zitat:
durch den einfach decompilierbaren Bytecode der Dot-Net-Sprachen und in Java exportiert jeder Verantwortliche, der Programm(Teile) in einer dieser Sprachen ausser Hauses gibt oder gelangen läßt, i.A. Firmengeheimnisse. ...
Da solche Firmengeheimnisse „kriegsentscheidend“ für eine Firma sind, kann tatsächlich das dann zufällig kurz danach auftauchende Konkurrenzprodukt aus chinesischer Produktion den Tod der Firma einleiten.
Natürlich gibt es Obfuskatoren, das Thema hatten wir ja schon.
Aber ich wage mal die Behauptung, dass viele kommerzielle Win8 (+ Phone) Apps in C++ geschrieben werden, um dieses Problem zu umgehen. Die syntaktischen Unterschiede, s.o., halten sich in Grenzen, beide greifen auf die selbe
API und Klassenbibliothek zu, usw.
Das ist sicher ein Gebiet, in dem Delphi mit nativer Cross Plattform Entwicklung punkten könnte, wenn die Qualität und Performance stimmen.
Performance ist allerdings so ein Gebiet, wo ich mir mehr von Delphi wünschen würde. Es gibt zwar Threads in der Sprache und ein wenig Angebot im Bibliotheksbereich (OmniThread). Aber verglichen mit dem, was es z.B. bei Intel oder MS gibt ist das recht dünn besetzt. Mit einer Visual Studio Express kann man seine C++ Threads mit C++ AMP auch auf der Grafikkarte laufen lassen, in zukünftigen Versionen wohl auch in der Cloud. Es gibt die Parallel Patterns Library, der Compiler hat einen Autovektorisierer und einen Autoparallelisierer.
Im Mobilbereich tun sich neue Problemfelder auf, z.B. ARM-Prozessoren mit "big little" Technik, also Prozessoren mit unterschiedlich schnellen Kernen, was Multithreading ein wenig komplitiert.
Alles Dinge, wo sich neue Delphis beweisen müssen. Im Moment halte ich es mit abwarten und C++ Programmieren.
