Unklarheiten zu Swift

Das sogenannte "Subset" von C++ dürfte Embedded C++ sein. Davon ließt man eher selten und ich weiß gar ned, ob es dafür einen Schalter beim GCC oder Clang gibt.

Wenn ich jetzt Wikipedia zitiere

Wikipedia schrieb:

The I/O Kit framework is implemented in a subset of C++ which omits features that Apple feels are unsafe for use in a multithreaded kernel (exceptions, multiple inheritance, templates, run-time type information). Embedded C++ was chosen partly because Apple believed developers would be more comfortable writing drivers in a more commonly used language than Objective-C, while still providing an object-oriented framework allowing device driver developers to focus on coding features specific to their hardware instead of reimplementing features common to any given device.

dann hat sich das mit dem abgespeckten C++ aus einer anderen Richtung her entwickelt. Ob das jetzt wirklich so zutrifft, weiß man nicht, da es dafür keinen Beleg gibt.

Nein, die C++-Runtime bekommt man selbst auf Embedded-Systemem mit erheblich unter 1MB (ROM+RAM) zum Laufen (mit RTTI, Exceptions und Multiple Inheritance, ggf. mit einer Teilmenge der Standardbibliothek). Apple hat das Zeug schlicht deshalb rausgelassen, weil sie diese Features für den Kernel ungeeignet oder nicht sinnvoll hielten. Für einige Sachen (z.B. RTTI) gibt es Ersatz in der libkern.

Erstens sind selbst die immer noch schneller als das Dispatching der Objective-C-Runtime und zweitens sind virtuelle Methoden mit Jumptables auch schon die teuerste von drei Implementierungs-Varianten in C++. Abhängig von der Deklaration in der Klasse (und ggf. Vererbung) gibt es in C++ drei Kategorien:
• virtuell (indirekter Call über Jumptable der Klasse)
• normal (direkter, absoluter Call)
• inline (gar kein Call – der Methoden-Code wird an der Aufruf-Stelle eingefügt und mit optimiert)

Und es macht absolut Sinn, alle drei Typen auch zu benutzen - je nach den Umständen.
Es ist in C++ absolut möglich, z.B. Unterkomponenten von Objekten sauber zu kapseln und zu abstrahieren, obwohl man in vielen Situationen gar keine Virtualität braucht, sondern die Klasse des Objekts an den meisten Aufruf-Stellen eh eindeutig ist. Und dann kann man die Klassen-Abstraktion eben ggf. komplett kostenlos machen, indem man z.B. mit Inline-Methoden arbeitet. In solchen Fällen kostet die saubere Abstraktion dann schlicht gar nichts. Und das ist der Witz an der Sache.

Objective-C hat meines Wissens nur genau einen Typ von Methoden-Aufruf:
• symbolisch (symbolischer Lookup, danach indirekter Call über Jumptable der Klasse)

Soweit ich bisher sehe, gibt es in Swift genausowenig eine Deklarations-Unterscheidung wie in Objective-C, sondern einfach immer nur func, aber wie es aussieht, müßte Swift in der Lage sein, selbständig zu entscheiden, welcher der insgesamt vier Aufruf-Typen jeweils benötigt wird bzw. möglich ist. Dafür ist gerade die Typsicherheit zur Compile-Zeit eine wesentliche Voraussetzung.

Swift ist in dieser Hinsicht moderner, weil man sich auch darum nicht mehr zu kümmern braucht und trotzdem (zumindest prinzipiell) alle Optimierungs-Vorteile haben kann, aber es wird eben interessant sein zu sehen, ob und inwieweit sie diese Möglichkeiten zur Optimierung auch tatsächlich im Compiler nutzen werden.



Tatsächlich? Bisher hatte ich eigentlich ziemlich positive Dinge über die Laufzeit-Performance von Windows Phone mitbekommen. Der wesentliche Unterschied scheint nach den bisherigen Berichten eher in der Reichhaltigkeit des Systems und vor allem der App-Ausstattung zu liegen, aber gerade weniger in der reinen Software-Performance.

Und Windows Phone basiert mindestens in den höheren Schichten ja gerade auch nicht primär auf C++, sondern auf C# und Silverlight.



Da bist Du selbst gleich in mehrfacher Hinsicht auf dem Holzweg.

1. C++ hat überhaupt keine Runtime im Sinn von Objective-C!
Das ist ja gerade einer der wesentlichen Unterschiede zwischen C++ und Objective-C!
Kompilierter C++-Code ist erst mal statisch (inklusive seiner Sprungtabellen) und benötigt keine Hilfe durch eine externe Runtime-Umgebung zu seiner Funktion. Das äußerste sind schon im Kompilat enthaltene Sprungtabellen für virtuelle Methoden, soweit die vorkommen und nicht schon zur Compile-Zeit auflösbar waren. Das war's im wesentlichen. Ansonsten kann man am kompilierten Code nicht mehr erkennen, daß das in der Source mal C++ gewesen war – es hätte genauso normales C mit expliziten Sprungtabellen sein können (über Funktionspointer-Arrays und entsprechende explizite Aufrufe).

2. Mir wäre neu, daß die Code-Größe für den Kernel irgendeine Relevanz hätte.

3. Effektiv haben alle nichttrivialen Projekte jeweils spezifische Coding Rules. Daß dabei bestimmte Konstrukte und Sprach-Features per Konvention ausgeschlossen werden, ist völlig normal und hängt mit der Funktionsweise des jeweiligen Projekts zusammen. Sowohl Exceptions als auch mehrfache Vererbung haben Konsequenzen, die in einem modularen Kernel zu Komplikationen führen könnten, weshalb es völlig normal ist, daß sie dort verboten sind. Dieselben oder vergleichbare Regeln können genauso auch in jedem anderen Projekt existieren.

4. Das ändert überhaupt nichts daran, daß es sich nach wie vor um C++ handelt, von dem diese beiden Features nur eher kleinere Randaspekte sind. Unter bestimmten Umständen interessante und relevante Randaspekte, aber unter den Bedingungen des Kernels riskante und auch deshalb verzichtbare.

Die Kosten für den dynamischen Dispatch sind eine Urban-Legend. In tatsächlichen Implementierungen nimmt sich das fast nichts gegenüber C++. Aber sogar die Kosten sind ein Teil eines Calls und ein Call ist wiederum ein Teil einer Programmausführung. Wir haben also den Zustand minimaler Kosten in einem Teil des Teils. Und in Objective-C kommst du einfach und schnell an C. Wer Performance als Problem eines Calls betrachtet, sollte sich seinen Code besser noch einmal genau anschauen.

Wichtiger aber: Objective-C ist für App-Entwicklung gedacht worden. Von Anfang an. Da spielt das ohnehin meist keine Rolle. Vor allem aber: Dynamisches Dispatching ist für App-Entwicklung gedacht worden. Es ist sogar mit der Erfindung der GUI gleichzeitig erfunden worden. Sogar an demselben Ort. Sogar von denselben Leuten. Möglicherweise wussten die ja, was sie tun.

Und wenn ich mir so Responder-Chain anschaue oder dynamische Info-Panels, die ich ohne Generics für irgendein Objekt irgendeines Typen codelos (aka Bindings) implementieren kann, so weiß ich auch, warum das zur gleichen Zeit von den gleichen Leuten an dem gleichen Ort erfunden wurde. Und ich weiß auch, warum das Windows zu den guten alten C++-Zeiten (aka statisches Dispatching) nie konnte und alles modal war. Das ist nämlich nicht theoretisch vom Himmel gefallen, sondern hat praktische Bedeutung. (Und – ups – die Software von Apple, die auch auf Windows läuft (iTunes) immer noch modal ist. Mit Objective-C wäre das nicht passiert.

Dass dann genau die so typsichere C++-Software auf Windows ungefähr 832648374682 Mal mehr abstürzte als die typunsichere Objective-C-Software auf OS X, ist dann wohl nur noch das schallende Gelächter der Wirklichkeit über die Sicherheit statischer Typisierung.

Ich weiß nicht, was du mit "im Sinne von Objective-C" meinst, aber C++ hat an verschiedenen Ecken Runtime-Zeug, das nicht in der Standardbibliothek ist. Global Scope Setup und Teardown, Stack Unwinding für Exceptions, RTTI und einiges mehr. Davon sieht man normalerweise nur nicht so viel.