Thema: C vs. C++ bzw. wo ist was sinnvoll?

[DDR-RAM]

Hi,

damit ihr gleich meine Meinung kennt, ich wäre dafür alles in C++ zu machen. Es gibt nur sehr wenige Funktionen, die C kann, aber C++ nicht.
C++ verfügt aber über Sprachmittel, die C nicht kennt, wichtigste ist wohl Klassen und das diese Funktionen usw. haben, na ihr kannt das ja

MfG
DDR-RAM

[Another Stupid Coder]

C++ wird zu fett und gibt durch die abstrakten teile zu wenig Kontrolle über den eigentlich produzierten Code, zudem ist es umständlicher C++ mit ASM zu mixen als C mit ASM...
ich bin eindeutig für C im Kernel. Über eine C++-API für Userland-Programme lässt sich aber reden

[stultus]

der kernel an sich sollte wirklich C sein, C++ würd ich aber (vorallem wegen der Klassen) durchaus für die GUI verwenden, da is das ganze sinnvoll

[Another Stupid Coder]

Nya, so wie die Pläne jetzt stehen, kommt die GUI doch in den Kernel.

[stultus]

Arrrgh, welche Diskusion hab ich verpasst? Grafik im Kernel ist ok, aber die GUI sollte ganz klar extra sein (wer will schon wegen nem kleinen bugfix den ganzen Kernel neu compilieren?)

[Another Stupid Coder]

Ganz meine Meinung...aber ich wüsste nicht, warum VESA sonst fix im Kernel sein sollte

[T0ast3r]

Also ich bin dafür, dass der grobe Kernel in C++ ist.
Die anderen sollen den Code ja auch verstehen können.
Ansonsten würde ich nur Assembler nehmen, aber C auf keinen Fall.

[Another Stupid Coder]

O_O Was ist an C unverständlich?

[TeeJay]

C finde ich beste Wahl.

Um C++ komplett nutzen zu können ist einiges an Vorarbeit notwendig was unnötig wäre das extra in den Kernel zu packen.

C alleine produziert zudem auch kleineren und schnelleren Code was für den Kernel ja sehr sinnvoll ist.

[DDR-RAM]

C finde ich beste Wahl.

Um C++ komplett nutzen zu können ist einiges an Vorarbeit notwendig was unnötig wäre das extra in den Kernel zu packen.

C alleine produziert zudem auch kleineren und schnelleren Code was für den Kernel ja sehr sinnvoll ist.

new/delete ist schnell gebastelt , ist ja nicht viel anders, wie malloc/free, wenn es ans exception-handling geht, dann ist tatsächlich Vorarbeit nötig. Man könnte es aber weglassen, wenn man es nicht will, allerdings hab ich es bis jetzt immer mit reingenommen, da damit leicht Möglichkeit, Fehler zu korrigieren oder Fehlermeldungen auszugeben.
RTTI würde ich im Kernel nicht verwenden, weil ich den Code net kenne. Mehrfachvererbung auch nicht, vor allem nicht von Interfaces.
Templates sind wahrscheinlich auch unnütz.
Operatorüberladung auch, aber ich würde sie nicht ausschließen wollen,
z.B. new/delete-Opeartor, evtl. Vergleichsoperatoren.

Wenn man auch Exception-Handling rauslässt,
hat man nen recht schlankes C++, das mit nem gutem Compiler garantiert nicht langsamer bzw. größer als entsprechendes C ist!
virtuelle Memberfunktionen würde ich Übrigens auch nicht ausschließen,
sie können enorm zur Abstraktion beitragen, was für den Kernel ja sehr sinnvoll ist

Wie berät sich eigentlich das Coreteam? Über PN's oder wohnt ihr zusammen?

MfG
DDR-RAM

[Roshl]

Also Operatorüberladung kann ziemlich nützlich sein, speziell bei String. Schnell ne Klasse String erstellt die nur einen char* enthält und dann paar Operatoren überladen schon kann man bequemer Vergleiche machen und braucht das olle strcmp nicht und strcat mit += ist auch recht praktisch.
Du hast Exceptionhandling für den kernel? kannste mir per PN mal verraten wie das funzt habe da keine Idee zu thx^^
Man kann mit C++ sogar kleineren Code erzeugen^^ ich habs jez so^^ Mischung aus C/C++ Code ist kleiner geworden um ca 2kb nur durchs umsetzten. Und Geschwindigkeitsmässig hat sich meiner Meinung nach wenig verändert
Naja und beraten tun wir uns über ICQ ganz einfach^^

[Jidder]

Bloß mit C++ arbeiten zu _wollen_ reicht auch nicht. Wer traut sich es zu durchzuplanen welche Klassen es gibt, welche Hierarchien es geben soll, etc.? Wenn man ein richtiges C++-Projekt nicht durchplant, kann man die Möglichkeiten von C++ gar nicht ausschöpfen, sondern hat nur Flickwerk. Ist da ein relativ offenes Modell in C nicht sinnvoller und einfacher?

Ein Projekt mit einem gewissen Einsatz von C++ wird zwangläufig abstrakt. Wenn aber der Kernel zu abstrakt wird, wird alles extrem unübersichtlich und  dann kann davon auch keiner mehr was lernen. (Es soll doch noch eine art "Lern-OS" werden, oder?)

Also eine String Klasse gehört auf keinen Fall in einen Kernel. Vor allem nicht in einen Mikrokernel. Im Kernel muss außer für Fehlermeldungen fast gar nicht mit Zeichenketten gearbeitet werden. Und Fehlermeldungen sind const char*'s ...

[mastermesh]

Der Kernel wird in C geschrieben werden. Die Leute, mit denen ich gesprochen habe, waren alle dafür, einen Microkernel zu schreiben. C++ im Microkernel ist IMHO Unsinn.

Die GUI (die übrigens NICHT Teil des Kernels wird) oder auch andere Teile des OSes können, wenn der Wunsch besteht, in C++ geschrieben werden.

[Another Stupid Coder]

Exakt meine Meinung, mastermesh

[DDR-RAM]

Der Kernel wird in C geschrieben werden. Die Leute, mit denen ich gesprochen habe, waren alle dafür, einen Microkernel zu schreiben. C++ im Microkernel ist IMHO Unsinn.

Meines Erachtens ist C++ im Microkernel überhaupt kein Unsinn.
Eventuell könnte man sich in der Mitte treffen und einige Sprachmittel von C++ nicht im Microkernel verwenden.
Ich sehe keine Vorteile von C gegenüber C++ (bin ich blind?).

MfG
DDR-RAM

[Jidder]

C++ hat auf jedenfall einige Nachteile:

- Overhead mit new/delete, Exceptions, etc ... (ok ist relativ gering)
- Treiberprogrammierer werden dann auch dazu gezwungen ihre Treiber in C++ zu schreiben. Ein Interface von C++ nach C ist wesentlich komplizierter als von C nach C++.
- Bei der Treiberprogrammierung kommen dazu noch üble Probleme bei der Kompatibilität (C-Funktionen können einheitlich exportiert/importiert werden, bei Klassen kocht hingegen jeder Compiler sein eigenes Süppchen). Die Treiberprogrammierer werden also auf den GCC festgenagelt.
- C++ bringt keinen Vorteil bei der Programmierung von Hardware. Hardware ist darauf ausgelegt von einem Assembler- oder C-Programm (oder einer anderen Prozeduralen Programmiersprache) bearbeitet zu werden. Also nicht Objektorientiert oder ähnliches. Große Teile der Kernels werden einfach aussehen wie C-Code.

[Roshl]

Was ich finde ist folgendes: C++ war immer nur als ERWEITERUNG zu C gedacht und so sollte es auch verwendet werden.
new und delete bringen GARKEINEN overhead wenn mans richtig macht.
Exceptions sind im Kernel ja an sich auch garnicht nötig.(Wenn der Kernel schon Fehlerstrotzend angelegt ist kann ja auch nix werden)
Andere Entwickler werden zu nichts gezwungen, die Treiber werden ja extra compiliert und dazugelinkt. Und man kann dem C++ Compiler auch sagen die Namen (in Klassen und vor Überladenes gehts natürlich nicht) nicht zu verunstalten indem man -extern "C"- davorsetzt
Die Hardware ist auf nichts anderes ausgelegt als vom Prozessor angesteuert zu werden und das geht nur über Maschinencode, ergo Assembler. Zeige mir ne Hardware die man mit C ansteuert, rofl.
Keine der beiden Sprachen hat vor oder Nachteile gegenüber der anderen. Mit entsprechender Arbeit kann jede die andere ersetzten. Man kann auch OOP mit C machen auch wenn das umständlich und komisch wird. Aber andersrum gibts genauso Dinge.
es ist absolut geschmackssache

BTW: informiert euch mal was ne Programmiersprache eigentlich ist;)

[DDR-RAM]

C++ hat auf jedenfall einige Nachteile:

- Overhead mit new/delete, Exceptions, etc ... (ok ist relativ gering)

der Overhead von new/delete geht ganz stark gegen 0.
EH hingegen ist zugegebener Maßen groß, ich würde auch nicht drauf bestehen. Aber was passiert eigentlich, wenn ein Treiber (also anderes Modul) eine Zugriffsverletzung "macht" ?

- Treiberprogrammierer werden dann auch dazu gezwungen ihre Treiber in C++ zu schreiben. Ein Interface von C++ nach C ist wesentlich komplizierter als von C nach C++.

Es ist schon klar, das man nem C++-Treiber ein C-Interface anbieten kann, aber nicht umgekehrt. Aber das es sehr kompliziert ist, ein C-Interface zu bauen, das intern auf C++ setzt, halte ich für naja sehr übertrieben.

- Bei der Treiberprogrammierung kommen dazu noch üble Probleme bei der Kompatibilität (C-Funktionen können einheitlich exportiert/importiert werden, bei Klassen kocht hingegen jeder Compiler sein eigenes Süppchen). Die Treiberprogrammierer werden also auf den GCC festgenagelt.

Verstehe ich nicht recht, die Treiber gehören doch nicht zum Mircokernel?
Werden also auch nicht mit denen zusammen kompiliert, bzw. gelinkt.
Wie wird überhaupt realisiert, das andere Module/Treiber auf den Microkernel zugreifen können? Sie müssen ja die Adressen kennen, also braucht man ne Art .LIB-Datei? Vielleicht hast du ja recht, aber ich will es erstnoch mal genau wissen.
Aber festgenagelt werden sie aber auf jedenfall nicht, wenn sie kein C verwenden, denn das C-Interface wird mit extern "C" deklariert.

- C++ bringt keinen Vorteil bei der Programmierung von Hardware. Hardware ist darauf ausgelegt von einem Assembler- oder C-Programm (oder einer anderen Prozeduralen Programmiersprache) bearbeitet zu werden. Also nicht Objektorientiert oder ähnliches. Große Teile der Kernels werden einfach aussehen wie C-Code.

Der Kernel selber, befasst sich gar nicht so viel mit Hardware, das machen doch eher die Treiber, der Kernel befasst sich mit Abstrakten Typen, wie Prozessen, die sehr wohl als Objekt darstellbar sind.

MfG
DDR-RAM

edit:
da war einer bisschen schneller als ich  

[Svenska]

Wenn ihr euch jetzt ne hitzige Diskussion liefert, was denn nun besser
sein soll, fällt das ganze Projekt mehr oder weniger ins Wasser.
Besinnt euch mal aufs Magazin zurueck...

Ich kann keine der beiden Sprachen, also auch nicht recht mitreden. Vom
Beginn war C geplant, jetzt soll es Cpp werden, mir ist es recht egal. Ich
komme dann später, wenn der Kernel eine Art Anwendungsumgebung
liefert. Und wie es scheint, kann das noch dauern...

C kam als Kernelsprache ins Gerede, weil es ein Lern-OS werden sollte,
kein grosses Etwas. Assembler war in dem Moment nämlich einfach zu
kompliziert. Besinnt euch mal ein bisschen auf die Urspruenge zurueck.
Es wird nämlich ganz sicher nichts, wenn jedes bisschen Planung wieder
umgeworfen wird. Aber das ist ein Nachteil der Demokratie, da irgendwie
keiner die Krone auf und das Zepter in der Hand hat.

Mein Machtwort und den Rest regelt ihr.

Svenska

[mastermesh]

Mein Machtwort und den Rest regelt ihr.

Bereits geregelt... zum größten Teil.