Wurde Apple in C++ programmiert?
-
Was hat das denn mit der EU zu tun? Ein Compiler ist kein Browser.
Aber technisch von ähnlich großem Aufwand.
Auch wird auf dem Markt stark gekämpft, ich sehe da viele Parallelen.
Nur fällt das wahrscheinlich den wenigsten Richtern so deutlich auf, weil sie keine Compiler verwenden.Nach eurer Logik dürfte MS dann auch Paint und Notepad nicht mit ausliefern oder was?
Wenn die mehr als ein Spielzeug wären, wäre sicher schon prozessiert worden.
-
Freezer- schrieb:
audacia schrieb:
Für den Rest soll AFAIK Objective-C benutzt worden sein. Das läge nahe, weil Cocoa auch primär eine ObjC-Schnittstelle ist.
Hi,
Ok danke, aber was ist an Objective-C denn besser als an C++? Ich höre Objective-C jetzt gerade zum ersten mal wenn ich ehrlich sein soll..
Es ist primär anders. Ob es besser ist soll jeder für sich entscheiden
-
Freezer- schrieb:
Außerdem habe Ich gehört Windows ist angeblich in C programmiert, aber ich frage mich wieso sie das nicht mit C++ gemacht haben?
Weil es mit C++ um durchschnittlich 7,62% langsamer wäre.
-
schtatischtiker schrieb:
Freezer- schrieb:
Außerdem habe Ich gehört Windows ist angeblich in C programmiert, aber ich frage mich wieso sie das nicht mit C++ gemacht haben?
Weil es mit C++ um durchschnittlich 7,62% langsamer wäre.
alles im kernel-mode von win ist in C. einige usermode-anwendungen sind in C++ gemacht worden. zur zeit der ersten nt-version war c++ kaum oder garnicht bekannt. hätte es c++ damals schon gegeben, hätten sie (wie ich ms so einschätze) im kernel auch c++ verwendet. das hätte ihnen wahrscheinlich ziemliche kopf- und bauchschmerzen bereitet, aber sie hätten's bestimmt durchgezogen (dann gäbs wohl auch eine kernel-mode variante des m$ 'component object model').
-
volkard schrieb:
Naja, es würde um Größenordnungen stabiler als in C laufen, weil man eine geordnete Fehlerbehandlung mit Exceptions hat und keine Ressourcenlöcher wegen der Destruktoren.
Lustig, als sie den linux Kernel mal auf g++ portiert haben um Kernel Module in c++ schreiben zu können (1992), haben sie das wieder rückgängig gemacht aus 2 Gründen: Es war viel zu langsam und das c++ exception handling war im Kernel unbenutzbar.
-
borg schrieb:
[Es war viel zu langsam und das c++ exception handling war im Kernel unbenutzbar.
oh nein, jetzt geht's wieder los. *cry* gleich haste die ganzen c++ fanatiker wie ~john, JustAnotherNoob, usw. auf'm hals.
-
Freezer schrieb:
Außerdem habe Ich gehört Windows ist angeblich in C programmiert, aber ich frage mich wieso sie das nicht mit C++ gemacht haben?
Um die C++ Programmierer fernzuhalten.
Linus Torvalds schrieb:
Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.
-
Merkwürdigerweise vermisst man beim Kernel-Programmieren C++ nicht.
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm
Da ist C einfach das richtige Werkzeug, abgesehen von diesen scheußlichen #define und dem blöden Deklarieren von Laufvariablen außerhalb der Schleife. Klassen und ihre Big Three fehlen einem kein Bißchen.Im User-Space, also außerhalb des Kernels, ist C++ die bessere Wahl, muss aber nicht sein.
-
borg schrieb:
volkard schrieb:
Naja, es würde um Größenordnungen stabiler als in C laufen, weil man eine geordnete Fehlerbehandlung mit Exceptions hat und keine Ressourcenlöcher wegen der Destruktoren.
Lustig, als sie den linux Kernel mal auf g++ portiert haben um Kernel Module in c++ schreiben zu können (1992), haben sie das wieder rückgängig gemacht aus 2 Gründen: Es war viel zu langsam und das c++ exception handling war im Kernel unbenutzbar.
1992, alles klar
Zitiert wenigstens etwas aktuelles, z.B. den L4-Microkernel, der ist in C++ geschrieben.
-
Was ist L4? Hab ich noch nie gehört, scheint unwichtig zu sein.
-
Freezer- schrieb:
Hi,
Ich habe gehört Apple Mac OS ist in C++ programmiert, stimmt das?
Die Treiber werden mit einem abgespecktem C++ geschrieben. Sonst kommt in MacOS X eher wenig C++ zum Einsatz. Die meisten Frameworks basieren auf Objective-C.
-
Der L4 Mikrokernel ist aber ein Kernel für Embedded Systems. Hab den Code noch da rumliegen, allerdings nur vom L4Ka::Pistachio. In meinem Augen wird nicht viel von den "ach so tollen C++ Features" verendet, sondern ist es eher fast nur C Code im C++.
-
supertux schrieb:
Der L4 Mikrokernel ist aber ein Kernel für Embedded Systems. Hab den Code noch da rumliegen, allerdings nur vom L4Ka::Pistachio. In meinem Augen wird nicht viel von den "ach so tollen C++ Features" verendet, sondern ist es eher fast nur C Code im C++.
Stimmt doch gar nicht, x86 ist die wichtigste Referenzplattform für L4.
Es hat doch nie jemand behauptet, dass man C++ Code so schreiben muss wie er in den ganzen Boost Dateien zu finden ist. Wenn ich C++ Code schreibe, dann sieht er auch leserlich aus (wobei ich glaube, dass die Boost Leute extra einen Obfuscator haben der die Release-Versionen erstellt).
-
OS-Progger schrieb:
x86 ist die wichtigste Referenzplattform für L4.
was bedeutet das schon?
-
Das bedeutet dass der Verbreitungsgrad begrenzt ist und man es beruhigt in die Tonne kloppen kann.
Habe ich zumindest irgendwann mal irgendwo von irgend jemandem gehört, der es spontan mal aufgeschnappt haben soll. Aber so ganz sicher, bin ich mir da nicht.
Klingt komisch, ist aber so.
-
volkard schrieb:
%fricky schrieb:
Freezer- schrieb:
Außerdem habe Ich gehört Windows ist angeblich in C programmiert, aber ich frage mich wieso sie das nicht mit C++ gemacht haben?
warum sollten sie? vorteile hätte es ja keine.
soll das hier der neue c++ flamethread werden?Naja, es würde um Größenordnungen stabiler als in C laufen, weil man eine geordnete Fehlerbehandlung mit Exceptions hat und keine Ressourcenlöcher wegen der Destruktoren. Durch die erhöhte Übersicht mancht man weniger Fehler und das senkt dei Entwicklungskosten. Außerdem kann man dadurch besser optimieren, was die Sache Ressourcensparender zur Laufzeit macht.
Wie stabiler soll der Linux-Kernel denn noch werden?
