C++Builder XE2: OS X und FireMonkey

[Zeus]

Teile der VCL sind auch in den Abstraktion Layer gegangen, die von Win32-VLC und Cross-Firemonekey benutzer wird ^^

[nn]

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

[audacia]

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

Aha, du hast den Eröffnungspost nicht gelesen

[nn]

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.

[audacia]

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

[nn]

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

[audacia]

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.

[nn]

audacia schrieb:

Du setzt F# produktiv ein? Nicht schlecht

Wie man es nimmt, es führt auch in C++ zu einem Programmierstil, der den Fähigkeiten des C++ Builders nicht entgegenkommt.

[Off Topic]
Wenn du etwas C# kannst, empfehle ich das Buch "Real World Functional Programming" (T. Petricek, J. Skeet) als Einstiegsdroge.

[audacia]

nn schrieb:

Wie man es nimmt, es führt auch in C++ zu einem Programmierstil, der den Fähigkeiten des C++ Builders nicht entgegenkommt.

Mangels Lambda-Funktionen, nehme ich an? Die vermisse ich auch so schon

nn schrieb:

[Off Topic]
Wenn du etwas C# kannst, empfehle ich das Buch "Real World Functional Programming" (T. Petricek, J. Skeet) als Einstiegsdroge.

Danke. Mal sehen; es ist schon länger her, daß ich Zeit und Muße für Fachliteratur aufbringen konnte. Davon habe ich schon im Studien- und Arbeitsalltag genug; wenn ich schon Zeit für ein Buch habe, dann lieber Thomas Mann.

[nn]

audacia schrieb:

Mangels Lambda-Funktionen, nehme ich an? Die vermisse ich auch so schon

Auch. Aber auto noch viel mehr. Typinferenz ist eine der Stärken von F#.
Sachen wie "Funktion die Tupel von irgendwas zurückgibt" haben in C++ recht längliche Namen.

Teile vom Buch gibt es auch im MSDN:
http://msdn.microsoft.com/en-us/library/hh314518.aspx

P.S. Wir kommen vom Thema ab.