> Nach Angaben der Entwickler werden Exceptions im Kernel sechsmal schneller behandelt als im Userspace mit g++, und sind mindestens neunmal schneller als ein Aufruf von printk im Kernel (das zur Ausgabe von Meldungen auf die Konsole dient). Auch die Geschwindigkeit von dynamischen Typprüfungen wurde verbessert.
Ist der Kernelspace so viel schneller als der Userspace oder wurde hier nur eine bessere (schnellere) Implementierung durchgeführt? Falls Ja, währe es mögliche diesen Geschwindigkeitsvorteil auf die libstdc++ zu übertragen?
Man kann im Kernelraum privilegierte Aktionen durchführen, die sonst nicht möglich sind. Dadurch höhere Geschwindigkeit möglich Außerdem weniger Adressraumwechsel, Prozesswechsel, etc... direkter Zugriff, etc.. blabla.
Resultat: ja, schneller, aber üblicherweise nicht übertragbar auf Userspace.
Wer sich mal die FAQ der LKML durchgelesen hat (http://www.tux.org/lkml/) wird wissen, dass es kurz- und mittelfristig wohl kein C++ im Vanillakernel geben wird. Auch wenn es durchaus Vorteile bringen würde bin auch ich dagegen.
C++ im kernel wäre durchaus begrüßenswert. Linux wäre ja nicht der erste Kernel der in C++ geschrieben ist. Wenn man C++ richtig einsetzt kann es sogar noch etwas schneller sein als C. Nicht zu schweigen das die Fehlerhäufigkeit bei schätzungsweise 10x seltener ist.
>Alessandro: Many people ask why the kernel >is written in C instead of C++. What is >your point against using C++ in the >kernel? What is the language you like >best, excluding C?
#Linus: C++ would have allowed us to use #certain compiler features that I would #have liked, and it was in fact used for a #very short timeperiod just before #releasing Linux-1.0. It turned out to not #be very useful, and I don't think we'll #ever end up trying that again, for a few #reasons.
#One reason is that C++ simply is a lot #more complicated, and the compiler often #does things behind the back of the #programmer that aren't at all obvious when #looking at the code locally. Yes, you can #avoid features like virtual classes and #avoid these things, but the point is that #C++ simply allows a lot that C doesn't #allow, and that can make finding the #problems later harder.
#Another reason was related to the above, #namely compiler speed and stability. #Because C++ is a more complex language, it #also has a propensity for a lot more #compiler bugs and compiles are usually #slower. This can be considered a compiler #implementation issue, but the basic #complexity of C++ certainly is something #that can be objectively considered to be #harmful for kernel development.
Ich habe übrigens mal ein Interview mit Linus bezüglich C++ im Kernel gelesen und da war er noch direkter.Wenn ich mich richtig erinnere war da ein Satz wie: "We tried C++ for the kernel but it was shit.When it comes to kernel development, C++ is crap".
Leider finde ich den Artikel nicht mehr.Ihr könnt ja mal googlen.
Von Jörg W Mittag am Mo, 1. November 2004 um 15:47 #
Die Frage ist ja auch: was bringt es?
Dort, wo es sinnvoll ist, ist der Kernel bereits heute weitestgehend objektorientiert. Für objektorientiertes Programmieren braucht man keine objektorientierte Programmiersprache, das geht auch in einer prozeduralen. Und dort, wo Objektorientierung im Kernel nicht sinnvoll ist, bringt C++ erst recht nichts. Wenn schon eine objektorientierte Programmiersprache her muss, dann doch wohl lieber Objective-C, das ist wenigstens rückwärtskompatibel zu C (im Gegensatz zu C++).
Kenn Obj-C net (weiß nur das es in MacOS X und NeXT STEP od. so verwendet wird/wurde). In wie fern ist Obj-C abwärtskopatiebler als C++? Ich meine man kann ja jedes ordentliche C Programm genauso mit nen C++ Kompiler kompelieren.
Von Jörg W Mittag am Mo, 1. November 2004 um 22:22 #
> In wie fern ist Obj-C abwärtskopatiebler als C++?
Objective-C ist eine Erweiterung von C, die die Syntax von C beibehält und lediglich ein paar neue reservierte Worte einführt. C++ dagegen ist eine von C abgeleitete, aber komplett unabhängige Programmiersprache.
> Ich meine man kann ja jedes ordentliche C Programm genauso mit nen C++ Kompiler kompelieren.
Meistens kann man das. Man weiß aber nicht unbedingt, was dabei herauskommt. Dieses Programm zum Beispiel hat zwei unterschiedliche Ausgaben, je nachdem, ob es mit einem C-Compiler oder einem C++-Compiler übersetzt wurde, weil es zwar sowohl gültiger C-Code als auch gültiger C++-Code ist, aber in beiden Programmiersprachen eine unterschiedliche Bedeutung hat:
#include int main(void) { int result = 1 //* */ 2 ; printf("Dies ist %s C-Compiler\n",(result?"kein":"ein"));
Von Jörg W Mittag am Di, 2. November 2004 um 17:34 #
Ich kann deiner überaus detaillierten, ausführlich erklärten und fundierten Analyse aufgrund meines beschränkten Intellektes nicht ganz folgen.
Möchtest du mich auffordern, mir Objective-C anzusehen? Das habe ich bereits getan.
Möchtest du aussagen, eine meiner Aussagen sei falsch oder ungenau? Dann würde mich doch interessieren, welche meiner Aussagen das war und inwiefern du der Meinung bist, sie sei falsch und ungenau.
Möchtest du damit aussagen, dass man Objective-C nicht mit einem C-Compiler übersetzen kann? Nun, das ist doch wohl offensichtlich und das habe ich auch nie behauptet.
Möchtest du damit aussagen, dass man C nicht mit einem Objective-C-Compiler übersetzen kann? Diese Aussage ist derart allgemein sicher richtig. Sofern der C-Code allerdings die paar reservierten Schlüsselwörter von Objective-C nicht verwendet, kann er von einem Objective-C-Compiler übersetzt werden. Damit ist gemischter C-/Objective-C-Code in derselben Datei möglich. Es wäre außerdem ein leichtes, dem Compiler einen Parameter zu verpassen, der diese paar Schlüsselwörter deaktiviert, so dass sich mit einem Objective-C-Compiler sogar beliebiger C-Code übersetzen lässt.
Möchtest du damit aussagen, dass man C-Code mit einem C++-Compiler übersetzen kann? Das ist falsch. C++ führt nicht nur neue reservierte Worte ein wie Objective-C sondern ändert auch die Semantik der Sprache. Natürlich tut Objective-C das auch, aber bei Objective-C (und bei allen anderen Mitgliedern der Objective-Sprachfamilie genauso) wird sehr darauf geachtet, dass die Änderungen, das Objektmodell etc. vollkommen orthogonal zur "Wirtssprache" sind. Tatsächlich gibt es bei Objective-C nur ganz wenige semantische und nur eine einzige syntaktische Änderung zu C, und diese Änderungen sind derart offensichtlich, dass man mit ziemlicher Sicherheit davon ausgehen kann, dass niemand sie übersehen oder verwechseln wird. (Ganz anders als bei C und C++, oder könntest du auf Anhieb sagen, was das von mir zitierte Programm tut? Ich meine, ich weiß, was es tut, und habe es trotzdem noch nicht verstanden.) Diese Orthogonalität bewirkt, dass die Objective-Sprachen weitestgehend unabhängig von der Wirtssprache sind, was sich zum einen darin niederschlägt, dass eine sehr hohe Abwärtskompatibilität besteht, zum anderen darin, dass Objective leicht auf andere Programmiersprachen portierbar ist (Objective-C++, Objective-Pascal, Objective-Fortran, Objective-Perl, Objective-TCL und Objective-COBOL (habe ich welche vergessen?)). Diese strenge Orthogonalität kann man besonders gut bei Objective-C++ sehen, dort führt sie nämlich zu der etwas paradoxen Situation, dass man es mit einer Sprache mit zwei voneinander unabhängigen Objektmodellen, dem von Simula bzw. C++ und dem von Smalltalk bzw. Objective zu tun hat, bei dem beispielsweise ein Objective-Objekt keine C++-Klasse instanziieren kann und umgekehrt.
Möchtest du damit aussagen, dass Objective-C aussieht wie Smalltalk? Das ist nicht wirklich überraschend, schließlich sind die Objective-Sprachen ja jeweils eine Portierung der Smalltalk-Semantik (soweit das eben möglich ist, ohne mit den anderen Entwurfszielen, z.B. Abwärtskompatibilität, Orthogonalität, möglichst "dünne" Schicht auf der Wirtssprache zu kollidieren; so musste zum Beispiel das Smalltalk-Prinzip "Alles ist ein Objekt" für Objective-C über Bord geworfen werden, weil man die elementaren Datentypen wie char oder int nicht einfach eliminieren oder in Objekte verwandeln konnte, ohne die Abwärtskompatibilität und Schlankheit aufzugeben) unter Benutzung von Smalltalk-Syntax auf eine prozedurale oder im Falle von Objective-C++ auf eine objektorientierte Sprache.
Vielleicht meint er einfach, dass Deine Kommentar-Spielerei ziemlich armselig ist. Und dass sowohl C-Obj. als offenbar auch ein C99 (s. u.) Zeilenkommentare kennen.
> man kann ja jedes ordentliche C Programm genauso mit nen C++ Kompiler kompelieren.
Das ist total falsch. C hat z.B. Datentypen fuer komplexe Zahlen, die C++ nicht kennt. C++ hat andere Regeln bzgl. Kompatiblitaet von Datentypen. C++ hat zusaetzliche reservierte Worte, sodass voellig legitimer und sauberer C-Code wie "int new = 0;" ungueltig ist. usw.
> C hat z.B. Datentypen fuer komplexe Zahlen, die C++ nicht kennt. Interessant. Bin eben noch net soo erfahren, war eben mehr ne Frage als ne Feststellung. Welche Datentypen sind denn das?
> C++ hat andere Regeln bzgl. Kompatiblitaet von Datentypen. In wie fern? Bzügl. C++ cast? Oder wie?
> C++ hat zusaetzliche reservierte Worte, sodass voellig legitimer und sauberer C-Code wie "int new = 0;" ungueltig ist. usw. Auch Obj.-C wird zusätzliche reservierte Wörter zu C haben. Es ist natürlich klar, das ich bei ordentlichen C Code meine, das es ein Code ist, der keine reservierten Wörter von C++ verwendet.
> Und dort, wo Objektorientierung im Kernel nicht sinnvoll ist, bringt C++ erst recht nichts.
Sicherlich, aber man muß ja zum glück nicht objektorientiert programmieren mit c++.
Davon abgesehen kann es schon Sinn machen einen Kernel objektorientiert zu schreiben, man findet sich leicht zurecht und kann sich auch gut einarbeiten. Es ist einfach praktisch, dem pic einen Zeiger auf ein Interrupt-Handle-Objekt zu geben welcher die weiteren Aktionen bestimmt und entsprechende Prozesse dem Scheduler zuspielt. Und daß das langsamer ist muß erstmal bewiesen werden.
Was für ein veralteter Mist auf den da herumgeritten wird. Heutzutage ist keines der Argumente wirklich real wenn ein bisschen Dispziplin eingehalten wird, was man ja von Kernel Programmierern erwarten kann.
Ein C++ Kernel hätte immense Code/Qualitätsvorteile, der das bestreitet hat noch einiges zu lernen.
Nein, C++ im Kernel wäre sicherlich nicht gut. Dadurch das der Kernel heute in C geschrieben ist und keine Unterstützung von OOP besitzt ist der Kernelcode sicherlich wesentlich besser als ein OOP Kernel.
Ich glaube das ein Kernel-Entwickler viel besser und sauberer programmiert wenn er dadurch durch eine Sprache wie C gezwungen wird. Obendrein würde C++ den Kernel nur noch größer machen...
Vieleicht wäre es allerdings von Vorteil wenn man Module in C++ schreiben könnte (und nur diese)....
C wird außerhalb von Kernelentwicklung immer seltener benutzt. Die meisten Anwendung sind heutzutage in Java, C#, C++ oder Sktiptsprachen geschreiben. Irgendwann werden die letzte C-Programmierer aussterben. Die Situation des Kerns wäre dann ziemlich ählich zu heutigen Cobol-Anwendung die fast niemand mehr pflegen kann.
Benutzung von C++ wäre zunächst eine Sicherung für die Zeiten nach dem Linus (möge er ewig leben!)
So langsam können auch die alten Programmierer mit OO umgehen oder werden einfach durch frische Leute ersetzt, die mit OO aufgewachsen sind. C++ fähiges Kernel kann man willkommen heißen
Die Behauptung, dass man mit einer weniger abstrakten Sprache wie C zu sauberer Programmierung gezwungen wird ist absurd. Dann müssten die Assembler-Programme die saubersten sein. Man schafft es mit jeder Sprache unsauber zu programmieren und bei C kann man das noch gut verstecken; nach dem Sinn: ein mal Schreiben, nie wieder Lesen, nie wieder Ändern, nie wieder Verstehen.
Das ist totaler Unsinn. OO ist ein Paradigma, was Du auch in jeder imperativen Sprache simulieren kannst, dazu benötigst Du kein C++ oder Java. Für Systemprogrammierung eignet sich C besonders, aus viele Gründen. Java wäre denkbar ungeeignet und C++ in weiten Bereichen von Kerneln auch. Dass man C++ und Java in anderen Bereichen sinnvoll(er als C) einsetzen kann ist kein Frage und entspricht ja auch den Tatsachen.
Das C vorläufig nicht aussterben wird ist relativ sicher, da auch im embedded Bereich, der ja sehr zukunftsträchtig ist, mit C stark umherhantiert wird.
Und nun ein Beispiel wie Du OO in C realisierst:
// 1. C++
class Foo {
public: Foo(); ~Foo(); int getValue();
private: int value_; };
Foo::Foo() { value_ = 1; }
~Foo::Foo(){}
int Foo::getValue() { return value_; }
Instanz/Aufruf:
int bar; Foo *foo = new Foo(); bar = foo->getValue();
// oder Foo foo2(); bar = foo2.getValue();
----
/* 2. C */
typedef struct { int value; int (*getValue)(Foo *foo); } Foo;
static int getValue(Foo *foo) { return foo->value; }
Instanz/Aufruf:
int bar; Foo *foo = malloc(sizeof(Foo)); foo->getValue = getValue; bar = foo->getValue(foo);
// oder Foo foo2; foo.getValue = getValue; bar = foo.getValue(foo);
C++ ist mehr verbose bei der Klassendeklaration, C bei der struct Initialisierung. C ist überraschenderweise in diesem Konzept sogar mächtiger, weil Du ohne Vererbungsnotwenigkeit, den getValue-Funktionspointer beliebig ändern kannst. Bei C++ würdest Du eine Vererbung + virtual Methoden dafür benötigen (natürlich gibts in C++ auch FPs und Methodenpointer, aber die kannst Du nicht auf einer Klassendefinition ändern, C schon). Deshalb ist C mathematisch gesehen auch mächtiger in den OO Konzepten, die C anbietet.
Ganz so einfach ist das nicht, da viele Punkte von OO nicht beachtet werden. Eine Typenbeschreibung wird benötigt (was C++ intern macht) um den korrekten Typ generisch zu erzeugen. Eine entsprechende new() delete() operation kann so ebenfalls implementiert werden. In etwa so:
Ein new (AOT_POINT_TYPE, 10, 20) liefert dann das richtig Objekt inklusive der Möglichkeit dem Constructor Parameter zu übergeben... Ein "delete" ruft auch den Destructor auf und prinzipiell läuft hier alles wie in C++... Der grosse Unterschied ist die fehlende Typensicherheit da man mit "void" Zeigern arbeiten muss. Ausserdem muss alles von Hand gemacht werden. Wenn jetzt noch Vererbung hinzukommt ("Strukturverlängerung") stösst man schnell an die Grenzen dessen was in C objektorientiert mit vertretbarem Aufwand machbar ist. Simulierung von OO in C stösst sehr schnell an seine Grenzen und von "mächtiger" kann nicht die Rede sein. "In gewissem Maße implementierbar" trifft es wohl eher.
Wie gesagt, mit Mächtigkeit bezog ich mich nicht auf gleichmächtige Sprachkonstrukte, sondern lediglich gleichmächtige Sprachsemantik, und die ist bei C trotz seiner Einfachheit gleichauf mit C++ gegeben. Vererbung ist eh ein ziemlich schlechtes Konzept, Kompositionen dienen der Wiederverwendbarkeit in viel besserem Maße (da eine Superklassenänderung bei vererbung mehr Änderung nach sich zieht, als eine Containeränderung auf beliebiger Ebene).
In Deinem Fall kann man aber relativ leicht eine C Abbildung finden (richtig hast Du bemerkt, das Templates nichts anderes als Makros sind):
struct Base1 { /* whatever */ };
struct Base2 { /* whatever */ };
struct Derived { Base1 base1; Base2 base2; }
Sicher etwas rudimentärer, aber durch Komposition möglich.
Nagut, Du hast die Sachen nur etwas modularisiert, vom Prinzip arbeitest Du mit FPs, wie ich auch. Vererbung ist in dem Sinne wie es C++ macht nicht möglich, dafür in einem kompositorischen Sinne, wie ich bereits beschrieben habe, durch FP-Änderung (und das sogar dynamisch im Gegensatz zu den vorgesehenen Sprachkonstrukten in C++). Typensicherheit ist ein guter Punkt, sagt aber nichts über die Sprachmächtigkeit aus, genauso wie auch Sichtbarkeitsregeln nichts über die Sprachmächtigkeit aussagen. Du kannst natürlich die die Abwärtskompatibilität mit C++ die gleichen Spielchen treiben, allerdings eben mit einer komplexeren Sprache. Ich präzisiere deshalb meine Aussage: Du kannst mit C gleichmächtig OOP betreiben, wie mit C++. Natürlich mit einigen Umständen wie fehlende Typsicherheit etc. (die imho bei C++ auch nicht weither ist, wenn man an Templates aka Makros denkt).
Dass der Kernel zwangsläufig grösser wird, wenn C++ umfassend genutzt wird, wage ich zu bezweifeln. Das sauberere Programmmieren in C dürfte allgemein angezweifelt werden. C++ hat viele Erweiterungen (und zum Teil Einschränkungen) gegenüber C nur aufgrund der zu rudimentären Programmierung (das Argument ist genauso absurd wie die Behauptung, dass man in Assembler zu saubererer Programmierung gezwungen würde als in C).
Du hast wohl noch nie was mit C++ gemacht ;) OOP ist nur eine der strategien die C++ unterstützt und selbst da kann man ganz fein tunen wieviel OO man will.
Von Jörg W Mittag am Di, 2. November 2004 um 00:46 #
> Dadurch das der Kernel heute in C geschrieben ist und keine Unterstützung von OOP besitzt ist der Kernelcode sicherlich wesentlich besser als ein OOP Kernel.
Linux enthält eine ganze Menge objektorientierten Code. Das mit Linux 2.6 eingeführte neue Unified Device/Driver Model z.B. ist objektorientiert. Und das ist auch gut so.
"Wenn man C++ richtig einsetzt kann es sogar noch etwas schneller sein als C."
Das ist mir neu, wo soll das bitte der Fall sein?
Ich bin kein Gegner von C++, habe selbst damit einiges gestrickt, aber in einem OS, das maßgeblich mit C geschrieben wurde und _für_ das _maßgeblich_ C entwickelt wurde mit C++ umgerzuhantieren ist ein ganz schlechte Idee, sofern Du es in allen Bereichen zuläßt (wie ich die Sache sehe, geht's aber primär um Device-Treiber und ähnliches Zeugs, also nicht unbedingt Kernel-Internas).
Der umgekehrte Fall macht da schon eher Sinn, wenn man von Anfang an C++ verwendet hätte, und dann schnelle Treiber in C geschrieben hätte, we es bei Be und OS/2 der Fall war...
Zum Thema Assembler: man kommt bei vielen Dingen in einem OS nicht um plattformspez. Assembler drumherum, vor allem was die Interrupt-Routinen angeht oder Teile der VM-Implementierung, die das MMU bzw. TLB-Mapping steuern müssen zwingend in Assembler geschrieben werden.
Ich hoffe Du weißt was inlinen bedeutet? Der Compiler *kopiert* den Funktionsrumpf/Klassenrumpf, der inline deklariert wurde an die Stelle wo er aufgerufen wird, um auf dem Stack keinen FCB alegen zu müssen, was rudimentär zu gewissen Performancegewinnen führt. Wenn Du aber mal nach Messungen googelst wirst Du schnell auf die Regel stoßen:
Inlining macht die Objects fett, fette Objects belegen mehr Speicher, mehr Speicherverbrauch führt zu häufigeren Speicherzugriffen, und am Ende ist nichts, mitunter sogar weniger Gewonnen. Es gibt ernsthafte C++ Gurus die gegen Inlining sind.
Templates sind der Gleiche irrsinn, sie blähen Klassen unnötig auf und machen _alle_ Klassen dicker, das führt zu dem gleichen Phänomen wie eben beschrieben. Bei kleinen C++ Anwendungen, die noch leicht im CPU-Cache untergebracht werden können stellt das kein Problem dar. Bei komplexen C++ Anwendungen aber schon, da mehr Speicherbedarf zu mehr Paging führt und deshalb sich extrem schlecht in der Performance niederschlägt. Als C++ Anfänger hab ich mit Templates und Inlining hantiert, später habe ich systematisch solche Sachen wieder entfernt, und siehe da, ich konnte den Speicherbedarf meiner Anwendung um 30% senken.
C++ ohne templates? bist du masochist? templates finde ich einen wichtigeren Vorteil gegenueber C als die Objektorientierung (die man in C relativ leicht nachbauen kann). Ohne templates,haette man nur typunsichere container,koennte keine generischen klassen/funktionen schreiben usw.... Zumal die ganze standardbibliothek querbeet templates nutzt. Naja und inlining,lass das mal den compiler entscheiden,wann er inlined und wann nicht ;-)
Naja C++ ohne templates....nene,dann waere C++ nichtmehr schoen.
Du sollst ja auch nicht alles auf biegen und brechen inlinen Bei kleinen funktionen ist es durchaus lohnend und der compiler macht es ja dann auch wenn nicht explizit "inline" angegeben ist.
Ist der Kernelspace so viel schneller als der Userspace oder wurde hier nur eine bessere (schnellere) Implementierung durchgeführt?
Falls Ja, währe es mögliche diesen Geschwindigkeitsvorteil auf die libstdc++ zu übertragen?
Außerdem weniger Adressraumwechsel, Prozesswechsel, etc...
direkter Zugriff, etc.. blabla.
Resultat: ja, schneller, aber üblicherweise nicht übertragbar auf Userspace.
Trotzden danke für Deine kompetente Antwort.
Wenn man C++ richtig einsetzt kann es sogar noch etwas schneller sein als C. Nicht zu schweigen das die Fehlerhäufigkeit bei schätzungsweise 10x seltener ist.
#Linus: C++ would have allowed us to use #certain compiler features that I would #have liked, and it was in fact used for a #very short timeperiod just before #releasing Linux-1.0. It turned out to not #be very useful, and I don't think we'll #ever end up trying that again, for a few #reasons.
#One reason is that C++ simply is a lot #more complicated, and the compiler often #does things behind the back of the #programmer that aren't at all obvious when #looking at the code locally. Yes, you can #avoid features like virtual classes and #avoid these things, but the point is that #C++ simply allows a lot that C doesn't #allow, and that can make finding the #problems later harder.
#Another reason was related to the above, #namely compiler speed and stability. #Because C++ is a more complex language, it #also has a propensity for a lot more #compiler bugs and compiles are usually #slower. This can be considered a compiler #implementation issue, but the basic #complexity of C++ certainly is something #that can be objectively considered to be #harmful for kernel development.
Quelle: http://www.linuxgazette.com/issue32/rubini.html
Ich habe übrigens mal ein Interview mit Linus bezüglich C++ im Kernel gelesen und da war er noch direkter.Wenn ich mich richtig erinnere war da ein Satz wie: "We tried C++ for the kernel but it was shit.When it comes to kernel development, C++ is crap".
Leider finde ich den Artikel nicht mehr.Ihr könnt ja mal googlen.
Dort, wo es sinnvoll ist, ist der Kernel bereits heute weitestgehend objektorientiert. Für objektorientiertes Programmieren braucht man keine objektorientierte Programmiersprache, das geht auch in einer prozeduralen. Und dort, wo Objektorientierung im Kernel nicht sinnvoll ist, bringt C++ erst recht nichts. Wenn schon eine objektorientierte Programmiersprache her muss, dann doch wohl lieber Objective-C, das ist wenigstens rückwärtskompatibel zu C (im Gegensatz zu C++).
jwm
In wie fern ist Obj-C abwärtskopatiebler als C++? Ich meine man kann ja jedes ordentliche C Programm genauso mit nen C++ Kompiler kompelieren.
Objective-C ist eine Erweiterung von C, die die Syntax von C beibehält und lediglich ein paar neue reservierte Worte einführt. C++ dagegen ist eine von C abgeleitete, aber komplett unabhängige Programmiersprache.
> Ich meine man kann ja jedes ordentliche C Programm genauso mit nen C++ Kompiler kompelieren.
Meistens kann man das. Man weiß aber nicht unbedingt, was dabei herauskommt. Dieses Programm zum Beispiel hat zwei unterschiedliche Ausgaben, je nachdem, ob es mit einem C-Compiler oder einem C++-Compiler übersetzt wurde, weil es zwar sowohl gültiger C-Code als auch gültiger C++-Code ist, aber in beiden Programmiersprachen eine unterschiedliche Bedeutung hat:
#include
int main(void) {
int result = 1 //* */ 2
;
printf("Dies ist %s C-Compiler\n",(result?"kein":"ein"));
return 0;
}
jwm
Möchtest du mich auffordern, mir Objective-C anzusehen? Das habe ich bereits getan.
Möchtest du aussagen, eine meiner Aussagen sei falsch oder ungenau? Dann würde mich doch interessieren, welche meiner Aussagen das war und inwiefern du der Meinung bist, sie sei falsch und ungenau.
Möchtest du damit aussagen, dass man Objective-C nicht mit einem C-Compiler übersetzen kann? Nun, das ist doch wohl offensichtlich und das habe ich auch nie behauptet.
Möchtest du damit aussagen, dass man C nicht mit einem Objective-C-Compiler übersetzen kann? Diese Aussage ist derart allgemein sicher richtig. Sofern der C-Code allerdings die paar reservierten Schlüsselwörter von Objective-C nicht verwendet, kann er von einem Objective-C-Compiler übersetzt werden. Damit ist gemischter C-/Objective-C-Code in derselben Datei möglich. Es wäre außerdem ein leichtes, dem Compiler einen Parameter zu verpassen, der diese paar Schlüsselwörter deaktiviert, so dass sich mit einem Objective-C-Compiler sogar beliebiger C-Code übersetzen lässt.
Möchtest du damit aussagen, dass man C-Code mit einem C++-Compiler übersetzen kann? Das ist falsch. C++ führt nicht nur neue reservierte Worte ein wie Objective-C sondern ändert auch die Semantik der Sprache. Natürlich tut Objective-C das auch, aber bei Objective-C (und bei allen anderen Mitgliedern der Objective-Sprachfamilie genauso) wird sehr darauf geachtet, dass die Änderungen, das Objektmodell etc. vollkommen orthogonal zur "Wirtssprache" sind. Tatsächlich gibt es bei Objective-C nur ganz wenige semantische und nur eine einzige syntaktische Änderung zu C, und diese Änderungen sind derart offensichtlich, dass man mit ziemlicher Sicherheit davon ausgehen kann, dass niemand sie übersehen oder verwechseln wird. (Ganz anders als bei C und C++, oder könntest du auf Anhieb sagen, was das von mir zitierte Programm tut? Ich meine, ich weiß, was es tut, und habe es trotzdem noch nicht verstanden.) Diese Orthogonalität bewirkt, dass die Objective-Sprachen weitestgehend unabhängig von der Wirtssprache sind, was sich zum einen darin niederschlägt, dass eine sehr hohe Abwärtskompatibilität besteht, zum anderen darin, dass Objective leicht auf andere Programmiersprachen portierbar ist (Objective-C++, Objective-Pascal, Objective-Fortran, Objective-Perl, Objective-TCL und Objective-COBOL (habe ich welche vergessen?)). Diese strenge Orthogonalität kann man besonders gut bei Objective-C++ sehen, dort führt sie nämlich zu der etwas paradoxen Situation, dass man es mit einer Sprache mit zwei voneinander unabhängigen Objektmodellen, dem von Simula bzw. C++ und dem von Smalltalk bzw. Objective zu tun hat, bei dem beispielsweise ein Objective-Objekt keine C++-Klasse instanziieren kann und umgekehrt.
Möchtest du damit aussagen, dass Objective-C aussieht wie Smalltalk? Das ist nicht wirklich überraschend, schließlich sind die Objective-Sprachen ja jeweils eine Portierung der Smalltalk-Semantik (soweit das eben möglich ist, ohne mit den anderen Entwurfszielen, z.B. Abwärtskompatibilität, Orthogonalität, möglichst "dünne" Schicht auf der Wirtssprache zu kollidieren; so musste zum Beispiel das Smalltalk-Prinzip "Alles ist ein Objekt" für Objective-C über Bord geworfen werden, weil man die elementaren Datentypen wie char oder int nicht einfach eliminieren oder in Objekte verwandeln konnte, ohne die Abwärtskompatibilität und Schlankheit aufzugeben) unter Benutzung von Smalltalk-Syntax auf eine prozedurale oder im Falle von Objective-C++ auf eine objektorientierte Sprache.
jwm
Somit kommt unter nen aktuellen C und C++ kompiler das selbe raus.
Das ist total falsch. C hat z.B. Datentypen fuer komplexe Zahlen, die C++ nicht kennt. C++ hat andere Regeln bzgl. Kompatiblitaet von Datentypen. C++ hat zusaetzliche reservierte Worte, sodass voellig legitimer und sauberer C-Code wie "int new = 0;" ungueltig ist. usw.
Interessant. Bin eben noch net soo erfahren, war eben mehr ne Frage als ne Feststellung. Welche Datentypen sind denn das?
> C++ hat andere Regeln bzgl. Kompatiblitaet von Datentypen.
In wie fern? Bzügl. C++ cast? Oder wie?
> C++ hat zusaetzliche reservierte Worte, sodass voellig legitimer und sauberer C-Code wie "int new = 0;" ungueltig ist. usw.
Auch Obj.-C wird zusätzliche reservierte Wörter zu C haben. Es ist natürlich klar, das ich bei ordentlichen C Code meine, das es ein Code ist, der keine reservierten Wörter von C++ verwendet.
Sicherlich, aber man muß ja zum glück nicht objektorientiert programmieren mit c++.
Davon abgesehen kann es schon Sinn machen einen Kernel objektorientiert zu schreiben, man findet sich leicht zurecht und kann sich auch gut einarbeiten. Es ist einfach praktisch, dem pic einen Zeiger auf ein Interrupt-Handle-Objekt zu geben welcher die weiteren Aktionen bestimmt und entsprechende Prozesse dem Scheduler zuspielt. Und daß das langsamer ist muß erstmal bewiesen werden.
Heutzutage ist keines der Argumente wirklich real wenn ein bisschen Dispziplin eingehalten wird,
was man ja von Kernel Programmierern erwarten kann.
Ein C++ Kernel hätte immense Code/Qualitätsvorteile, der das bestreitet hat noch einiges zu lernen.
Ich glaube das ein Kernel-Entwickler viel besser und sauberer programmiert wenn er dadurch durch eine Sprache wie C gezwungen wird. Obendrein würde C++ den Kernel nur noch größer machen...
Vieleicht wäre es allerdings von Vorteil wenn man Module in C++ schreiben könnte (und nur diese)....
Die meisten Anwendung sind heutzutage in Java, C#, C++ oder Sktiptsprachen geschreiben.
Irgendwann werden die letzte C-Programmierer aussterben.
Die Situation des Kerns wäre dann ziemlich ählich zu heutigen Cobol-Anwendung die fast niemand mehr pflegen kann.
Benutzung von C++ wäre zunächst eine Sicherung für die Zeiten nach dem Linus (möge er ewig leben!)
So langsam können auch die alten Programmierer mit OO umgehen oder werden
einfach durch frische Leute ersetzt, die mit OO aufgewachsen sind.
C++ fähiges Kernel kann man willkommen heißen
Die Behauptung, dass man mit einer weniger abstrakten Sprache wie C zu sauberer Programmierung gezwungen wird ist absurd. Dann müssten die Assembler-Programme die saubersten sein.
Man schafft es mit jeder Sprache unsauber zu programmieren und bei C kann man
das noch gut verstecken; nach dem Sinn: ein mal Schreiben, nie wieder Lesen, nie wieder Ändern, nie wieder Verstehen.
Das C vorläufig nicht aussterben wird ist relativ sicher, da auch im embedded Bereich, der ja sehr zukunftsträchtig ist, mit C stark umherhantiert wird.
Und nun ein Beispiel wie Du OO in C realisierst:
// 1. C++
class Foo {
public:
Foo();
~Foo();
int getValue();
private:
int value_;
};
Foo::Foo() {
value_ = 1;
}
~Foo::Foo(){}
int Foo::getValue() {
return value_;
}
Instanz/Aufruf:
int bar;
Foo *foo = new Foo();
bar = foo->getValue();
// oder
Foo foo2();
bar = foo2.getValue();
----
/* 2. C */
typedef struct {
int value;
int (*getValue)(Foo *foo);
} Foo;
static int getValue(Foo *foo) {
return foo->value;
}
Instanz/Aufruf:
int bar;
Foo *foo = malloc(sizeof(Foo));
foo->getValue = getValue;
bar = foo->getValue(foo);
// oder
Foo foo2;
foo.getValue = getValue;
bar = foo.getValue(foo);
C++ ist mehr verbose bei der Klassendeklaration, C bei der struct Initialisierung. C ist überraschenderweise in diesem Konzept sogar mächtiger, weil Du ohne Vererbungsnotwenigkeit, den getValue-Funktionspointer beliebig ändern kannst. Bei C++ würdest Du eine Vererbung + virtual Methoden dafür benötigen (natürlich gibts in C++ auch FPs und Methodenpointer, aber die kannst Du nicht auf einer Klassendefinition ändern, C schon). Deshalb ist C mathematisch gesehen auch mächtiger in den OO Konzepten, die C anbietet.
In etwa so:
/* forward declarations */
static void *ctor (void *_self, va_list *app);
static void *dtor (void *_self);
static void stats (const AotPoint *pt);
/* class type */
static const AotPointClass _pointclass = {
{ sizeof (AotPoint), "AotPoint", ctor, dtor },
stats
};
const void* AOT_POINT_TYPE = &_pointclass;
* --------------------------------------------------------------
* constructor - put initialization code here
* --------------------------------------------------------------
*/
static void *ctor (void *_self, va_list *app)
{
AotPoint *self = _self;
self->x = va_arg (*app, int);
self->y = va_arg (*app, int);
return self;
}
/* --------------------------------------------------------------
* destructor - put cleanup code here
* --------------------------------------------------------------
*/
static void *dtor (void *_self)
{
return _self;
}
...
Ein new (AOT_POINT_TYPE, 10, 20) liefert dann das richtig Objekt inklusive der Möglichkeit dem Constructor Parameter zu übergeben...
Ein "delete" ruft auch den Destructor auf und prinzipiell läuft hier alles wie in C++...
Der grosse Unterschied ist die fehlende Typensicherheit da man mit "void" Zeigern arbeiten muss. Ausserdem muss alles von Hand gemacht werden. Wenn jetzt noch Vererbung hinzukommt ("Strukturverlängerung") stösst man schnell an die Grenzen dessen was in C objektorientiert mit vertretbarem Aufwand machbar ist.
Simulierung von OO in C stösst sehr schnell an seine Grenzen und von "mächtiger" kann nicht die Rede sein. "In gewissem Maße implementierbar" trifft es wohl eher.
mach mal das in C:
class Base1 {};
class Base2() {};
class Derived : public Base1, public Base2 {};
Dann müsste man noch templates mit macros machen und function und opertaor overloading geht gar nicht!
Vererbung ist eh ein ziemlich schlechtes Konzept, Kompositionen dienen der Wiederverwendbarkeit in viel besserem Maße (da eine Superklassenänderung bei vererbung mehr Änderung nach sich zieht, als eine Containeränderung auf beliebiger Ebene).
In Deinem Fall kann man aber relativ leicht eine C Abbildung finden (richtig hast Du bemerkt, das Templates nichts anderes als Makros sind):
struct Base1 {
/* whatever */
};
struct Base2 {
/* whatever */
};
struct Derived {
Base1 base1;
Base2 base2;
}
Sicher etwas rudimentärer, aber durch Komposition möglich.
Und macros sollten verb(r)annt werden!
Ich präzisiere deshalb meine Aussage: Du kannst mit C gleichmächtig OOP betreiben, wie mit C++. Natürlich mit einigen Umständen wie fehlende Typsicherheit etc. (die imho bei C++ auch nicht weither ist, wenn man an Templates aka Makros denkt).
OOP ist nur eine der strategien die C++ unterstützt und selbst da kann man ganz fein tunen wieviel OO man will.
Linux enthält eine ganze Menge objektorientierten Code. Das mit Linux 2.6 eingeführte neue Unified Device/Driver Model z.B. ist objektorientiert. Und das ist auch gut so.
jwm
Das ist mir neu, wo soll das bitte der Fall sein?
Ich bin kein Gegner von C++, habe selbst damit einiges gestrickt, aber in einem OS, das maßgeblich mit C geschrieben wurde und _für_ das _maßgeblich_ C entwickelt wurde mit C++ umgerzuhantieren ist ein ganz schlechte Idee, sofern Du es in allen Bereichen zuläßt (wie ich die Sache sehe, geht's aber primär um Device-Treiber und ähnliches Zeugs, also nicht unbedingt Kernel-Internas).
Der umgekehrte Fall macht da schon eher Sinn, wenn man von Anfang an C++ verwendet hätte, und dann schnelle Treiber in C geschrieben hätte, we es bei Be und OS/2 der Fall war...
Zum Thema Assembler: man kommt bei vielen Dingen in einem OS nicht um plattformspez. Assembler drumherum, vor allem was die Interrupt-Routinen angeht oder Teile der VM-Implementierung, die das MMU bzw. TLB-Mapping steuern müssen zwingend in Assembler geschrieben werden.
ganz einfach, wenn man templates nimmt anstelle von void* kann der compiler inlinen.
>und _für_ das _maßgeblich_ C entwickelt wurde
Ach! dreimal darfst du raten für welches system Stroustrup C++ entwickelt hat :)
...erstaunlich sachliche diskussion heute hier übrigens. ich bin erstaunt!
Der Compiler *kopiert* den Funktionsrumpf/Klassenrumpf, der inline deklariert wurde an die Stelle wo er aufgerufen wird, um auf dem Stack keinen FCB alegen zu müssen, was rudimentär zu gewissen Performancegewinnen führt. Wenn Du aber mal nach Messungen googelst wirst Du schnell auf die Regel stoßen:
Inlining macht die Objects fett, fette Objects belegen mehr Speicher, mehr Speicherverbrauch führt zu häufigeren Speicherzugriffen, und am Ende ist nichts, mitunter sogar weniger Gewonnen. Es gibt ernsthafte C++ Gurus die gegen Inlining sind.
Templates sind der Gleiche irrsinn, sie blähen Klassen unnötig auf und machen _alle_ Klassen dicker, das führt zu dem gleichen Phänomen wie eben beschrieben. Bei kleinen C++ Anwendungen, die noch leicht im CPU-Cache untergebracht werden können stellt das kein Problem dar. Bei komplexen C++ Anwendungen aber schon, da mehr Speicherbedarf zu mehr Paging führt und deshalb sich extrem schlecht in der Performance niederschlägt. Als C++ Anfänger hab ich mit Templates und Inlining hantiert, später habe ich systematisch solche Sachen wieder entfernt, und siehe da, ich konnte den Speicherbedarf meiner Anwendung um 30% senken.
Zumal die ganze standardbibliothek querbeet templates nutzt. Naja und inlining,lass das mal den compiler entscheiden,wann er inlined und wann nicht ;-)
Naja C++ ohne templates....nene,dann waere C++ nichtmehr schoen.
Deswegen heißt sie ja STL: Standard Template Library.