C++Builder XE2: OS X und FireMonkey
-
http://www.drbob42.com/examines/examinE0.htm
Hat jemand damit schon herumexperimentiert?
-
Was möchtest den wissen? Evtl. kann ich es on-the-Fly testen?
-
Neinnein, ich habe es selbst auch schon ausprobiert
Ich will nur wissen, ob es dazu bereits andere Meinungen und Erfahrungen gibt.
-
audacia schrieb:
Neinnein, ich habe es selbst auch schon ausprobiert
Ich will nur wissen, ob es dazu bereits andere Meinungen und Erfahrungen gibt.Wie ist den deine Meinung dazu? Hab dich ja auch in der Beta gelesen.
-
VergissEs schrieb:
Wie ist den deine Meinung dazu?
Momentan habe ich kein Projekt, für das eine Mac-Version dringend gebraucht würde. Es gibt zwar "nice-to-have"-Anfragen, aber solange alles in der obligatorischen Windows-VM läuft, beklagt sich niemand. Insofern ist mein Interesse daran eher akademischer Art.
Beim Deployment holpert es noch ein wenig, aber die Geschichte mit den Remote-Profilen funktioniert, finde ich, sehr gut und ist ein eleganter Workaround für die Tatsache, daß Apple seine SDK-Header nicht weiterlizenziert. Das Remote-Debugging funktioniert aus der XP-VM heraus auch sehr schön, deutlich fixer jedenfalls als der alte Remote-Debugger.
Soweit zu den eindeutig positiven Dingen. Obgleich ich Verständnis für die Idee hinter FireMonkey habe, bevorzuge ich die Verwendung nativer Controls - u.a. deshalb benutze ich die VCL für meine Anwendungen. Also wäre die Mac-Geschichte für mich interessanter, wenn es Unterstützung für die nativen Cocoa-Bindings gäbe. Netterweise gibt es einen einfachen Mechanismus für ObjC-Bindings in Delphi, der sich auch in C++ verwenden läßt. Aber vermutlich ist man momentan mit ObjC, XCode und Interface Builder trotzdem produktiver.
Vielleicht ist meine Vorstellung davon auch völlig anachronistisch, und es wird bald völlig normal sein, daß UI-Frameworks wie WPF oder FireMonkey nicht mehr die nativen Steuerelemente benutzen. Andererseits scheinen weder OS X/iOS noch die neuesten Entwicklungen bei Windows 8 diesen Ansatz zu fördern: sowohl bei Apple als auch in Metro wird großer Wert auf die Einheitlichkeit des UI und die Verwendung nativer Steuerelemente gelegt. Also bin ich auch nur verhalten begeistert von der Vorstellung, daß der zukünftige Win8/Metro-Support in Delphi und C++Builder im Wesentlichen aus FireMonkey bestehen soll.
VergissEs schrieb:
Hab dich ja auch in der Beta gelesen.
(Dir ist schon klar, daß FT-Teilnehmer ein NDA unterschrieben haben, das den öffentlichen Austausch darüber untersagt? Das beinhaltet auch Stellungnahmen zur Teilnahme am FT.)
-
audacia schrieb:
Dir ist schon klar, daß FT-Teilnehmer ein NDA unterschrieben haben, das den öffentlichen Austausch darüber untersagt? Das beinhaltet auch Stellungnahmen zur Teilnahme am FT.)
Sorry wird nie gar nie nicht wieder nie vorkommen
Da ich leider nicht im Besitz der neuen XE2 Version bin darf ich ja nun leider auch nicht meine Meinung dazu abgeben, da das ja die Erfahrungen aus der Beta währen.
Tschuldigung halte mich nun raus.
-
VergissEs schrieb:
Sorry wird nie gar nie nicht wieder nie vorkommen
Schon okay. Mir ist es eh egal. Ich wollte nur darauf aufmerksam machen, bevor du dich um Kopf und Kragen plauderst
VergissEs schrieb:
Da ich leider nicht im Besitz der neuen XE2 Version bin darf ich ja nun leider auch nicht meine Meinung dazu abgeben, da das ja die Erfahrungen aus der Beta währen.
Oder aus der Trial?
VergissEs schrieb:
Tschuldigung halte mich nun raus.
Bitte nicht!
-
audacia schrieb:
Momentan habe ich kein Projekt, für das eine Mac-Version dringend gebraucht würde.
Das geht mir ähnlich. Meine Programm laufen hauptsächlich auf Industrie-PCs. Ein Industrie-Mac ist quasi ein Widerspruch in sich.
FireMonkey halte ich im Moment für was zum Spielen und Anschauen. Bevor der neue Compiler nicht draußen ist und von uns als brauchbar befunden wurde, wird sich das nicht ändern.
Spannend finde ich das Bildchen in der Roadmap Ankündigung des neuen Produktmanagers:
http://blogs.embarcadero.com/jtembarcadero/2011/09/17/may-the-roadmap-rise-with-you/Erste Zeile: Windows Apple iOS Android (man beachte die Abwesenheit von Linux)
Zweite Zeile: Intel/ARM war bekannt, OpenCL (ist C basiert, im Gegensatz zu den anderen eher C++ basierten Ansätzen, können sie halt besser einen neuen Dialekt machen, weil kein echter Delphi Coder was in C-Syntax kaufen wird.)
Dritte Zeile: Naja, komische Kombination
-
nn schrieb:
Spannend finde ich das Bildchen in der Roadmap Ankündigung des neuen Produktmanagers:
http://blogs.embarcadero.com/jtembarcadero/2011/09/17/may-the-roadmap-rise-with-you/Wenn man sich da mal nicht zu viel vorgenommen hat. Mit fortwährendem Windows-Support wäre ich schon glücklich, alles andere ist für mich Bonus.
Nicht, daß ich etwas dagegen hätte, daß man neue Nutzerkreise erschließen will.nn schrieb:
(man beachte die Abwesenheit von Linux)
Aus den Kommentaren:
John Ray Thomas schrieb:
yes the penguin is an accidental omission.
nn schrieb:
Dritte Zeile: Naja, komische Kombination
Das lese ich als: "64-Bit-Unterstützung für Delphi und C++". Für Delphi ist das ja schon verfügbar (und es taugt: meine Erfahrung ist mit "it just works" am besten beschrieben). Für C++ soll es XE3 werden.
-
audacia schrieb:
Für C++ soll es XE3 werden.
Auf den neuen Compiler bin ich echt mal gespannt.
Der letzte Wechsel der Compilerarchitektur war ja genaugenommen der von Borland C++ 4.52 auf 5.0. Und der war doch etwas holprig. Der "neue Compiler" im C++ Builder X zählt nicht wirklich.
Der 5.0 (Compilerversion nicht C++ Builder) war die erste Version mit integrierter STL, damals war gerade die allereste Ausgabe von Nicolai Josuttis "Die C++ Standardbibliothek" erschienen. Mit fast jedem Beispiel im Buch konnte man beim 5.0 einen internal Compiler Error erzeugen.
Ich glaube es wurden dreimal neue CDs nachgeliefert, bis das Teil endlich halbwegs lief.
Nächstes Jahr kommt die C++11 Version des Buches, passend für XE3.
-
nn schrieb:
Der letzte Wechsel der Compilerarchitektur war ja genaugenommen der von Borland C++ 4.52 auf 5.0.
Was wurde da denn gewechselt? Wenn ich mich nicht irre, ist der Compiler seit jeher der gleiche.
nn schrieb:
Der "neue Compiler" im C++ Builder X zählt nicht wirklich.
Der EDG-basierte? Nein, der zählt nicht, der konnte die BCC-Extensions nicht
-
audacia schrieb:
Was wurde da denn gewechselt? Wenn ich mich nicht irre, ist der Compiler seit jeher der gleiche.
Ob es eine völlige Neuentwicklung war, kann ich nicht sagen. Ich habe mit den Versionen ab 2.0 zu tun gehabt, meine eigene Sammlung beginnt mit der 4.0 CD.
Damals waren die Unterschiede zwischen den Versionen viel größer als heute, 16/32 Bit-Umstellung, Exception Handling, RTTI, Templates, Namespaces usw., in jeder Version gab es bedeutende Änderungen.
Der 5er fühlte sich auf jeden Fall an wie ein neuer Compiler und hatte entsprechend viele Bugs. Es war die erste Version, die es mit der STL aufnehmen konnte, vorher gab es nur unvollständige Implementierungen.
In gewisser Weise erinnert das an Boost und die heutigen Compiler.
Und: Als damals der Compiler stabil war (5.02), kam der Wechsel von der OWL zur VCL. Heute kommt der Wechsel zu Firemonkey.
-
nn schrieb:
[...] Der 5er fühlte sich auf jeden Fall an wie ein neuer Compiler und hatte entsprechend viele Bugs. Es war die erste Version, die es mit der STL aufnehmen konnte, vorher gab es nur unvollständige Implementierungen.
In gewisser Weise erinnert das an Boost und die heutigen Compiler.
Okay, klingt sinnvoll. Die erste Version, mit der ich Erfahrungen hatte, war 5.2 (C++Builder 1), und die erste, die ich produktiv verwendet habe, 5.6 (C++Builder 6), also kann ich da nicht mitreden.
nn schrieb:
Und: Als damals der Compiler stabil war (5.02), kam der Wechsel von der OWL zur VCL. Heute kommt der Wechsel zu Firemonkey.
Wobei das nicht vergleichbar ist. Die VCL wird ja der Ankündigung nach weiter entwickelt und unterstützt. Was sollten sie auch anderes machen, wo doch die IDE selbst die VCL verwendet, ganz zu schweigen von einem Haufen zahlender Kunden. Ich denke, daß man sich an C++BuilderX gut genug erinnern kann, um denselben Fehler nicht nocheinmal machen zu wollen.
Aber zurück zum Thema: hat jemand die Mac-Unterstützung oder FireMonkey schon ausprobiert und Meinungen dazu?
-
Teile der VCL sind auch in den Abstraktion Layer gegangen, die von Win32-VLC und Cross-Firemonekey benutzer wird ^^
-
audacia schrieb:
Aber zurück zum Thema: hat jemand die Mac-Unterstützung oder FireMonkey schon ausprobiert und Meinungen dazu?
Mangels Mac habe ich mir nur mal den Inhalt der diversen Verzeichnisse angesehen und in der Hilfe gestöbert.
Da beim C++ Builder Includedateien und Libs von X-Code kopiert werden, kann man da möglicherweise einiges ansprechen, was in Delphi noch nicht geht. Der Compiler ist also binärkompatibel mit den X-Code Libs. Sowas würde ich mir im Bezug auf VC++ auch wünschen.
Und wenn wir sowas für Linux kriegen, wäre das toll.Die Hilfe schein mir noch nicht so ganz Cross Plattform zu sein. Wenn man in den Delphi RTL Quellen stöbert, sieht man, dass viele Sachen (z.B. run um Threads) für den Mac mit den entsprechenden Posix Funktionen implementiert sind.
Teilweise haben Klassen in der Mac Version andere Member oder Member mit anderen Typen. Die Hilfe beschreibt aber nur die Windows Sicht. (Schaut euch z.B. mal TThread an.)Da hab ich noch so ein bischen Sorge, wenn sich das ganze auf noch mehr Plattformen ausdehnt. Sowohl was die Doku, als auch die Delphi RTL angeht. Beides wird sich etwas aufblähen müssen.
Zeus schrieb:
Teile der VCL sind auch in den Abstraktion Layer gegangen, die von Win32-VLC und Cross-Firemonekey benutzer wird ^^
Außerdem wurden Teile der Posix API in Pascal umgesetzt, wie ich beim Studium der Verzeichnissse festgestellt habe.
Hier ist übrigens ein kleiner Artikel, der den Entwicklungsvorgang für den Mac in Bildern zeigt:
http://www.drbob42.com/examines/examinE0.htm
-
Zeus schrieb:
Teile der VCL sind auch in den Abstraktion Layer gegangen, die von Win32-VLC und Cross-Firemonekey benutzer wird ^^
Bitte was?
nn schrieb:
Da beim C++ Builder Includedateien und Libs von X-Code kopiert werden, kann man da möglicherweise einiges ansprechen, was in Delphi noch nicht geht. Der Compiler ist also binärkompatibel mit den X-Code Libs. Sowas würde ich mir im Bezug auf VC++ auch wünschen.
Oh ja. Das ist allerdings nicht wahrscheinlich; der neue Win64-Compiler wird vermutlich ELF benutzen, nicht COFF.
nn schrieb:
Hier ist übrigens ein kleiner Artikel, der den Entwicklungsvorgang für den Mac in Bildern zeigt:
http://www.drbob42.com/examines/examinE0.htmAha, du hast den Eröffnungspost nicht gelesen
-
audacia schrieb:
Aha, du hast den Eröffnungspost nicht gelesen
Doch, aber seit gestern schon wieder vergessen.
Aber noch mal zurück zum Thema:
Wie siehst du die Entwicklung von CrossPlatform FireMonkey Apps in C++, abseits der GUI-Entwicklung ?
Kleines Beispiel, was mich da bei dem stört, was ich sehe:
TThread::Priority ist unter Windows vom Typ TThreadPriority, unter Posix vom Typ int. Nun ist die Threadpriorität unter Windows eigentlich auch ein numerischer Wert, TThreadPriority ist eine Umsetzung von defines aus der WinAPI. Gut, man kann sagen der int ist für den Posix Programmierer verständlicher, man kann aber auch den Verdacht haben, es musste alles sehr schnell gehen und man hat auf eine einheitliche Schnittstelle verzichtet, der Anwender kann ja einfach ein paar ifdefs schreiben.
Codestellen dieser Art findet man sehr häufig, wenn man im Bereich System und Dateien sucht. Ist sicher auch eine Folge davon, dass man quasi mit der Windows Version anfängt und jetzt Intel/ARM, Windows/Posix, Win32/Win64/WinRT und Mac/Linux/iOS/Android hinein #ifdef't.
Das lässt für mich nur den Schluss zu, wenn Crossplattform, dann abseits der Oberfläche möglichst bei C++ und boost bleiben, um die Delphi RTL einen weiten Bogen machen.
-
nn schrieb:
Kleines Beispiel, was mich da bei dem stört, was ich sehe:
TThread::Priority ist unter Windows vom Typ TThreadPriority, unter Posix vom Typ int. Nun ist die Threadpriorität unter Windows eigentlich auch ein numerischer Wert, TThreadPriority ist eine Umsetzung von defines aus der WinAPI. Gut, man kann sagen der int ist für den Posix Programmierer verständlicher, man kann aber auch den Verdacht haben, es musste alles sehr schnell gehen und man hat auf eine einheitliche Schnittstelle verzichtet, der Anwender kann ja einfach ein paar ifdefs schreiben.
Zunächst geht ein großer Teil der POSIX-Unterstützung in der RTL auf Kylix zurück. Da ist sicherlich viel liegengeblieben, was einer Revision bedürfte.
Ansonsten finde ich den Ansatz hier nicht falsch; wenn ich die Dokumentation richtig verstehe, sind die Thread-Priority-Ansätze von Windows und POSIX einfach nicht kompatibel (in Windows gibt es klarer definierte Zwischenstufen, in POSIX gibt es die Policies SCHED_RR, SCHED_FIFO und SCHED_OTHER, von denen nur die ersten beiden überhaupt ein Prioritätsmanagement zulassen, jedoch dem root-User vorbehalten sind). Wie sinnvoll ist es also, ein plattformunabhängiges TThread::SetPriority() anzubieten, wenn der Unix-Benutzer dafür root braucht und sich noch für eine Policy entscheiden muß, der Windows-Benutzer dafür recht genau angeben kann, wozu er die Priorität braucht und außerdem nur das THREAD_SET_INFORMATION-Token benötigt?
nn schrieb:
Codestellen dieser Art findet man sehr häufig, wenn man im Bereich System und Dateien sucht. Ist sicher auch eine Folge davon, dass man quasi mit der Windows Version anfängt und jetzt Intel/ARM, Windows/Posix, Win32/Win64/WinRT und Mac/Linux/iOS/Android hinein #ifdef't.
Für Dateien gibt es ja das IOUtils-Unit, das speziell wegen der Plattformunabhängigkeit eingeführt wurde und die Sache etwas vereinfachen soll. Das Dateimanagement in SysUtils.pas ist sicherlich sperriger und systemspezifischer.
nn schrieb:
Das lässt für mich nur den Schluss zu, wenn Crossplattform, dann abseits der Oberfläche möglichst bei C++ und boost bleiben, um die Delphi RTL einen weiten Bogen machen.
Kann man machen. Aber ob dir Boost und die C++-Standardbibliothek wirklich so viel bieten wie die Delphi-RTL? Das Problem mit der Threadpriorität hat man bei Boost offenbar "gelöst", indem man einfach gar keinen Weg zum Ändern der Priorität anbietet. Das macht die Sache IMO nicht besser.
Übrigens noch eine interessante Neuerung abseits vom Cross-Platform-Support: BCC unterstützt jetzt, von drei Ausnahmen abgesehen, RTTI auf demselben Niveau wie der Delphi-Compiler. In Zukunft wird z.B. die Einbindung einer Skriptsprache oder das Databinding also zu einem reinen Vergnügen
(Die drei Ausnahmen sind Custom Attributes, Record-Methoden und Type Info-Rooting.)
-
audacia schrieb:
Zunächst geht ein großer Teil der POSIX-Unterstützung in der RTL auf Kylix zurück. Da ist sicherlich viel liegengeblieben, was einer Revision bedürfte.
Wie wahrscheinlich ist es, das so grundlegende Dinge später noch mal geändert werden ?
audacia schrieb:
Ansonsten finde ich den Ansatz hier nicht falsch;
...
Das Dateimanagement in SysUtils.pas ist sicherlich sperriger und systemspezifischer.Dem stimme ich grundsätzlich zu. Das Beispiel sollte nur zeigen, dass "write once, run everywhere" Ansätze mit FireMonkey nur in sehr GUI-lastigen Fällen möglich sein werden.
Für etwas speziellere Anwendungen ist eine intensive Auseinandersetzung mit den Zielplattformen nötig. Wer bisher sehr VCL-lastigen Code geschrieben hat, betritt da auf jeden Fall Neuland. Wer schon mit anderen Entwicklungsumgebungen auf diesen Plattformen arbeitet, wird sich sicher fragen, warum er zwischen seinem Code und dem OS noch einen in Pascal geschriebenen Layer verwenden soll.
audacia schrieb:
Kann man machen. Aber ob dir Boost und die C++-Standardbibliothek wirklich so viel bieten wie die Delphi-RTL?
Das kommt sicher auf die Art des Codes an. Ich schreibe nur etwa 10 % meines C++ Codes mit dem C++ Builder und versichere dir, ich kann gut ohne die Delphi RTL leben. Was nicht bedeuten soll, das man alles fertig in boost findet. Aber mein C++ Code kommuniziert entweder mit externer Hardware (RS232, CAN, LIN, Ethernet, ...) oder macht komplexe mathematische Berechnungen. Den Rest machen C# und neuerdings F#.
-
nn schrieb:
Wie wahrscheinlich ist es, das so grundlegende Dinge später noch mal geändert werden ?
In dem Fall: unwahrscheinlich. Allgemein kann es sein, daß jemand eine Schnittstelle drüberbaut, die die Sache etwas besser abstrahiert, wie eben IOUtils.pas .
audacia schrieb:
Dem stimme ich grundsätzlich zu. Das Beispiel sollte nur zeigen, dass "write once, run everywhere" Ansätze mit FireMonkey nur in sehr GUI-lastigen Fällen möglich sein werden.
Wenn du mich fragst, ist "write once, run everywhere" eine Utopie. Schon bei Java hieß das "..., debug everywhere"
nn schrieb:
Für etwas speziellere Anwendungen ist eine intensive Auseinandersetzung mit den Zielplattformen nötig. Wer bisher sehr VCL-lastigen Code geschrieben hat, betritt da auf jeden Fall Neuland. Wer schon mit anderen Entwicklungsumgebungen auf diesen Plattformen arbeitet, wird sich sicher fragen, warum er zwischen seinem Code und dem OS noch einen in Pascal geschriebenen Layer verwenden soll.
Okay, ist ein Punkt. Ich würde sagen "wenn es dem Komfort nützt". Aber natürlich, wenn ich groß mit #ifdefs herumhantieren muß, verwende ich gleich die nativen Schnittstellen.
nn schrieb:
Den Rest machen C# und neuerdings F#.
Du setzt F# produktiv ein? Nicht schlecht
Ich hab mir schon länger vorgenommen, das mal näher anzusehen. Eigentlich finde ich ja Haskell ganz toll, aber dafür gibt es weder Tool-Support noch eine gescheite Einbindung für .NET, Java oder Delphi. In dieser Hinsicht drängt sich F# geradezu auf.