Amin Negm-Awad schrieb:
Es lässt sich ja leicht überprüfen, ob ich hier eine Diskussion für bendet erklärt habe. Such mal.
Du liegst also mal wieder falsch.
MCDan schrieb:
Mir kommt es so vor, als würde Apple Teile von macOS/iOS komplett neu entwickeln, vermutlich sogar in Swift anstelle von Objective-C.
Amin Negm-Awad schrieb:
Nur damit noch twas Leben in der Bude bleibt: Als letzter etwas zum Thema schreiben und dann die Diskussion für beendet zu erklären, ist auch etwas was meine 7-jährige Tochter nicht mehr macht.leftshift schrieb:
@WernerB
Heute werden aber schon Nägel reingehauen.
Drei Dinge:
1. Solaris hat genau wie Linux einen monolithischen Kernel (nur weil Du das bei Linux so betonst)
2. Das Orakel Solaris fallen gelassen hat kannst Du ja nun schwerlich den Linuxcodern anlasten. Da musst Du Dich bei Larry beschweren.
3. das mit den 'grössten Feinden' klingt nun wirklich bisserl zu dramatisch
Also und jetzt sollte mal Schluss sein mit diesem Thema. Hier ging es um Xcode. Ich klinke mich aus.
Waaas, die ist schon sieben? Wo ist die Zeit hin? +scnr+ 
helmut72 schrieb:
Mich würde ein swiftOS nicht wundern.MCDan schrieb:
Mir kommt es so vor, als würde Apple Teile von macOS/iOS komplett neu entwickeln, vermutlich sogar in Swift anstelle von Objective-C.
rumme schrieb:
Na ja, spätestens beim Kernel sollte mit den "Experimenten" Schluss sein. Btw. ein Editor ist – sogar bei Xcode – auch nur eine Anwendung bzw. eine Komponente einer Anwendung.
Es wird erst so richtig spannend, wenn/sobald Cupertino anfängt, von allen Applications zu nutzende Systemkomponenten dazwischen anzufassen – also Quartz z.B.
helmut72 schrieb:
Mich würde ein swiftOS nicht wundern.
WernerB schrieb:
Swift aufgrund der Speichereffizienz
torquato schrieb:
Optionals verbraten ein ganzes Byte extra. Besonders speichereffizient ist das nicht gerade.
WernerB schrieb:
Dazu ist der Unterbau in C viel zu groß.helmut72 schrieb:
Mich würde ein swiftOS nicht wundern.MCDan schrieb:
Mir kommt es so vor, als würde Apple Teile von macOS/iOS komplett neu entwickeln, vermutlich sogar in Swift anstelle von Objective-C.
macmoonshine schrieb:
Auf einer 64-Bit Maschine sind das wegen des Alignments mindestens 8 Byte.
macmoonshine schrieb:
Da Optionals aber auf Enums basieren, vermute ich, dass es sogar noch ein paar Byte mehr sein werden.
torquato schrieb:
Ist das nicht Prozessorabhängiig? Oder ist das wirklich zwingend so?macmoonshine schrieb:
Auf einer 64-Bit Maschine sind das wegen des Alignments mindestens 8 Byte.
Außerdem dürfte das doch auch Typen betreffen, die kein Optional sind, oder?
Die Größe einer Enum hängt von der Menge der cases und (hauptsächlich) des größten assoziierten Wertes ab, falls vorhanden. Im Falle eines Optionals: der assoziierte Wert plus ein Byte für den zusätzlichen none-case.macmoonshine schrieb:
Da Optionals aber auf Enums basieren, vermute ich, dass es sogar noch ein paar Byte mehr sein werden.
Der Overhead, der Dir vorschwebt, liegt wohl eher in der Runtime (witnesstable, etc.) und nicht in dem Typen selbst.
WernerB schrieb:
Ich meine damit Optionals - die haben sicherlich auch andere Vorzüge.
Amin Negm-Awad schrieb:
Ich gehe mal davon aus, dass der zugrunde liegende Typ in aller Regel integral ist. Dann ist ein zusätzlicher integraler Wert eine Verdopplung. Das ist mehr als Bitknauserei.