Wurde Apple in C++ programmiert?
-
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..
-
Echt? Kann mich nicht daran erinnern. Erinnern kann ich mich nur an "Weil es so viel OO statisch getypt machen will und gleichzeitig möglichst kompatibel zu C bleiben will."
Hab nachgeschlagen, hast recht.
stimmt, früher waren wenigstens noch qbasic bzw. gwbasic dabei. aber heute haste ja .NET auf jeder windoof-kiste und da ist bestimmt auch ein C#-compiler mit drauf.
Keine Ahnung. Aber wahrscheinlich nicht.
Ist sicher nur das Framework, ohne irgendwas weiteres.
-
Die EU hätte ihre Freude
Auch wieder wahr.
Daran hatte ich noch nie gedacht.
-
Ok danke, aber was ist an Objective-C denn besser als an C++?
Weiß ich leider nicht.
Was ich aber weiß, ist daß sich Objective-C später von C abgespalten hat als C++.
Nach allem, was ich so höre, is Objective-C vollständig Syntax-kompatibel zu C, was für C++ nur mit einigen Ausnahmen gilt.Ich glaube ich, irgendwo gelesen zu haben, daß Objective-C stärker auf das Nachrichten-Modell setzt. Ich hab mir irgendwann mal die Syntax angeschaut: aber da waren so viele seltsame eckige Klammern drin, daß ich's wieder gelassen habe.
Schau bei Interesse mal hier:
http://de.wikipedia.org/wiki/Objective-C
-
mngbd schrieb:
stimmt, früher waren wenigstens noch qbasic bzw. gwbasic dabei. aber heute haste ja .NET auf jeder windoof-kiste und da ist bestimmt auch ein C#-compiler mit drauf.
Keine Ahnung. Aber wahrscheinlich nicht.
Ist sicher nur das Framework, ohne irgendwas weiteres.Hm, bei mir in %WINDIR%\Microsoft.NET\Framework\v2.0.50727 ist csc.exe enthalten. Ich hab zwar auch das SDK installiert, allerdings befinden sich dessen Binaries vermutlich nicht in diesem Ordner.
-
Hm, bei mir in %WINDIR%\Microsoft.NET\Framework\v2.0.50727 ist csc.exe enthalten.
Wenn das Out-of-the-box so wäre, würde ich das für eine Gute Sache halten.
Vielleicht hat's die EU einfach übersehen?
-
Was hat das denn mit der EU zu tun? Ein Compiler ist kein Browser. Nach eurer Logik dürfte MS dann auch Paint und Notepad nicht mit ausliefern oder was?
-
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).