Feedback: C++ für kommende Windows Phone Releases.
-
Guten Morgen,
Da ich gerade gross in die Materie eingestiegen bin wollte ich fragen, ob es hier bereits C++-ler gibt, die auf Windows Phone am programmieren sind (vermutlich eher nicht?). Für alle, die es nicht wissen: Es gibt auf dieser Platform für Dritte keinen Zugang zur C++ Toolchain (Microsoft, Adobe etc. können bereits native Apps deployen; siehe Office, Reader, ...). Genau dies wird aber nun gefordert, und zwar nicht von wenigen. Achtung: Hier geht es nicht unbedingt um C++/CLI, sondern viel mehr um natives C++ bzw. C++11.
Mit der Windows 8 Preview von vergangenem Jahr werden sowohl C++, als auch C++/CLI wieder den anderen Sprachen (C#, VB.NET) gleichgestellt. Klar, man bastelt wieder irgendwas Microsoft spezifisches, sobald man UIs oder Interoperation nutzt. Auf der anderen Seite kann man in der Applikation auch normales, reines C++ nutzen (wie man es in C++/CLI kann). Man kann bestehenden Code 1:1 übernehmen und es läuft. Dasselbe sollte es auch für Windows Phone geben.
Microsoft nimmt derzeit bereitwillig Feedback entgegen zu diesen Themen auf der eigens dafür eingerichteten Site wpdev.uservoice.com, und der Punkt Native SDK to support C++ Development steht sehr weit oben in der Liste. Falls es euch also im entferntesten interessiert, könnt ihr ja mal reinschauen und euren Senf dazu abgeben. Vielleicht bekommen wir ja dann innert Jahresfrist die erste mobile Plattform seit langem, auf der man wieder gescheit mit C++ programmieren kann.
-
Um mit iOS und Android mithalten zu können, muß MS irgendwann nativen Programme erlauben müssen. Denn auch wenn viele Hotspot/VM-Verfechter es immer wieder predigen: nein, Byte-Code ist und kann nicht so effizient sein, wie nativer Code. Das hat letztens Herb Sutter klar gemacht, wo er genau das sagte: iOS hat mit seinen nativen 3rd-Party-Programmen einen Vorteil, wenn es um Batterielaufzeit und Ausführungsgeschwindigkeit bei mobilen Systemen, wie Tablet-PCs und Smartphones geht.
Auch Google mußte das irgenwann einsehen, in dem sie dann das NDK raus brachten. Auch wenn sie noch empfehlen Java zu nutzen, und NDK nur für Performance-kritische Aufgaben empfehlen, ist es ein Eingeständnis.
MS wird also nicht drum rum kommen, C++ und andere Sprachen bzw. allgemein nativen Code zu erlauben.
-
Artchi schrieb:
Denn auch wenn viele Hotspot/VM-Verfechter es immer wieder predigen: nein, Byte-Code ist und kann nicht so effizient sein, wie nativer Code.
Das liegt aber nicht am Byte-Code. Byte-Code kann man ja in genau für diese Maschine optimierten nativen Code übersetzen. Nur die zusätzlichen VMs machen es immer langsamer.
-
CodedByte schrieb:
Artchi schrieb:
Denn auch wenn viele Hotspot/VM-Verfechter es immer wieder predigen: nein, Byte-Code ist und kann nicht so effizient sein, wie nativer Code.
Das liegt aber nicht am Byte-Code. Byte-Code kann man ja in genau für diese Maschine optimierten nativen Code übersetzen. Nur die zusätzlichen VMs machen es immer langsamer.
Der JIT-Compiler leistet in der Tat wahre Wunder, die CLR ist nicht mit Dalvik auf Android zu vergleichen. Das liegt nicht zu letzt auch an einigen Designentscheidungen, die bei Java vor vielen Jahren getätigt worden und nicht mehr reparierbar sind (Objekte nur per Referenz etc.). C# und auch VB.NET sind Java in Sachen Effizienz in mancher Hinsicht überlegen, jedoch reden wir hier von Kleinstgeräten, wo es von der Performance her trotzdem schnell kritisch wird. Das Problem ist nicht der Byte-Code, das Problem sind die Rules, welche von den VMs durchgesetzt werden müssen bis zum letzen Atemzug.
Ich bin auf dieses Thema gestossen, weil ich mit C# XNA eine Partikel-Simulation programmieren wollte. Die Simulation war zu langsam ab einer relativ kleinen Anzahl Partikel, weil nur schon jeder Array-Zugriff doppelt und dreifach gegen IndexOutOfRange-Conditions abgesichert wird (Enumerator -> List -> Array
). Partikel lesen, Partikel updaten, Partikel als einfache Pixel in eine Textur zeichnen (ja, das Zeichnen in eine Textur funktioniert ebenfalls über Arrays, die gechecked werden...) - das alles verschwendet massiv Zeit mit diesen unnötigen Checks. Mit nativem C++, auch wenn sandboxed hätte man solche Probleme eher selten oder zumindest weniger Stark ausgeprägt.
-
bei c# haste doch unsafe: Unsafe code increases the performance by getting rid of array bounds checks
-
unsafe schrieb:
bei c# haste doch unsafe: Unsafe code increases the performance by getting rid of array bounds checks
unsafeerzeugt unverifiable Code. Dieser wird von der mobilen CLR aus Sicherheitsgründen nicht akzeptiert, da er ein FullTrust Environment für die Ausführung voraussetzt. Die Apps laufen jedoch mit sehr eingeschränkten Berechtigungen (ist auch richtig so), vergleichbar mit denen im Web Browser.