C vs C++ bei OSDEV

Erhard Henkes

Kapselung ( engl.: information hiding oder encapsulation ) ist in der Tat der wesentliche Effekt der Objektorientierung. Das ist ein klarer Pluspunkt für C++.
http://www.henkessoft.de/C++/C++/kapselung.htm

Zeus

Information Hiding kann man in C auch betreiben, aber Encapsulation nicht. Zwei Begriffe die nicht äquivalent sind.

abc.w

Erhard Henkes schrieb:

.. Ich persönlich bin überrascht, wie gut man in C einen Kernel programmieren kann. ...

Liegt es vielleicht daran, dass die Tools gcc und binutils verwendet werden?

Erhard Henkes

Dass man auch in C++ interessante OS bauen kann, wird hier von James Molloy und Jörg Pfähler ("bluecode") gezeigt:
http://www.lowlevel.eu/wiki/Pedigree

dot

Imo gibt es nur einen einzigen Grund heutzutage noch C zu benutzen: Wenn es für eine Zielplattform keinen C++ Compiler gibt. Alleine schon wegen templates, overloading und RAII würde ich mich jederzeit für C++ entscheiden wenn ich die Wahl hätte. Dass C++ einen inhärenten Performancenachteil gegenüber C hätte ist ein Märchen, man kann genausogut Beispiele aufzeigen wo das Gegenteil der Fall ist (z.B. das allseits beliebte std::sort vs qsort()). Natürlich hat C++ einige Sprachfeatures die einen gewissen Overhead mit sich bringen. Allerdings darf man dabei nicht vergessen dass, wenn man ähnliche Systeme direkt in C implementieren würde, am Ende C Code rauskommt der mehr oder weniger genau das tut was der C++ Compiler einem abnehmen würde und daher auch vergleichbaren Overhead mit sich bringt (Beispiel die gern verteufelten virtuelle Funktionen: In C greift man dafür eben in irgendeiner Form auf Function Pointer zurück und hat am Ende den selben Overhead).

Erhard Henkes

Information Hiding kann man in C auch betreiben

Kannst du dies bitte an Beispielen darstellen?

taljeth

foo.h:

struct foo;

struct foo* create_foo(void);
void do_it(struct foo* xyz);

foo.c:

#include "foo.h"

struct foo {
    int bar;
    char baz[42];
};

struct foo* create_foo(void) { return calloc(1, sizeof(struct foo)); }
void do_it(struct foo* xyz) { ... }

Von außen sieht niemand, wie eine struct foo tatsächlich aussieht, man hantiert nur mit Pointern darauf.

Artchi

Stellen wir fest:
1. Es ist sehr nützlich Kapselung/Information-Hiding (ich meine nicht Implementation-Hiding ähnlich Pimpl) zu betreiben.
2. Es ist mit C-Mitteln in gewisser Weise möglich.

Meine Frage: ist es in der C-Welt Usus, es so zu machen? Falls nicht, bitte ich um eine Erklärung, warum es nicht Usus ist.

Zeus

@taljeth
Danke, genau sowas hatte ich Sinn.

Man sieht aber auch es gibt Probleme, wenn man die Idee von vorher aufgreift, Polymorphie durch Funktionszeiger zu emulieren.

dot

Artchi schrieb:

Meine Frage: ist es in der C-Welt Usus, es so zu machen? Falls nicht, bitte ich um eine Erklärung, warum es nicht Usus ist.

Afaik is das was taljeth beschrieben hat in C eine relativ gängige Sache.

Erhard Henkes

http://d3s.mff.cuni.cz/publications/Decky-FormallyVerifiedOS.pdf
Chapter 2.2 The C Programming Language:

A large majority of OSes is coded in the C programming language (HelenOS is no exception to this). The choice of C in the case of kernel is usually wellmotivated, since the C language was designed specifically for implementing system software [10]: It is reasonably low-level in the sense that it allows to access the memory and other hardware resources with similar effectiveness as from assembler; It also requires almost no run-time support and it exports many features of the von Neumann hardware architecture to the programmer in a very straightforward, but still relatively portable way.

However, what is the biggest advantage of C in terms of run-time performance is also the biggest weakness for formal reasoning. The permissive memory access model of C, the lack of any reference safety enforcement, the weak type system and generally little semantic information in the code – all these properties do not allow to make many general assumptions about the code.

abc.w

... However, what is the biggest advantage of C in terms of run-time performance is also the biggest weakness for formal reasoning. The permissive memory access model of C, the lack of any reference safety enforcement, the weak type system and generally little semantic information in the code – all these properties do not allow to make many general assumptions about the code.

Viele Denkfallen und Fehler im C Quellcode lassen sich mit Hilfe der statischen Code-Analyse Tools wie splint aufdecken und vermeiden (es gibt auch entsprechende Tools für C++, kenne leider keine kostenlosen...).
Das andere Problem und meiner Meinung nach, das schwergewichtigere, ist:

In C, almost everything is left to the programmer who is free to set the rules.

Erhard Henkes

... almost everything is left to the programmer who is free to set the rules.

Entwickler eines eigenen OS schätzen diese Freiheiten und sollten damit auch umgehen können.

dot

C++ schränkt diese Freiheiten in keiner Form ein...

Mr X

abc.w schrieb:

... However, what is the biggest advantage of C in terms of run-time performance is also the biggest weakness for formal reasoning. The permissive memory access model of C, the lack of any reference safety enforcement, the weak type system and generally little semantic information in the code – all these properties do not allow to make many general assumptions about the code.

Viele Denkfallen und Fehler im C Quellcode lassen sich mit Hilfe der statischen Code-Analyse Tools wie splint aufdecken und vermeiden (es gibt auch entsprechende Tools für C++, kenne leider keine kostenlosen...).
Das andere Problem und meiner Meinung nach, das schwergewichtigere, ist:

In C, almost everything is left to the programmer who is free to set the rules.

Splint... Ich habs tatsächlich versucht, es hat _nur_ Müll ausgegeben, keinen sinnvollen Hinweis unter ca. 5000 Hinweisen.

Cppcheck find ich persönlich besser, kann mit C und C++ umgehen.

abc.w

Mr X schrieb:

Splint... Ich habs tatsächlich versucht, es hat _nur_ Müll ausgegeben, keinen sinnvollen Hinweis unter ca. 5000 Hinweisen.

Ja, ich weiss, dass man Tausende Warnungen bekommt, aber ich habe die Erfahrung gemacht, dass jede Warnung einen Bug bedeuten kann... d.h. in den 5000 Warnungen würde ich jetzt 5000 potentielle Bugs sehen...

Mr X schrieb:

Cppcheck find ich persönlich besser, kann mit C und C++ umgehen.

Danke für den Tipp!

Erhard Henkes

MrX ist einer der führenden Developer von PrettyOS. Wenn er sagt, dass die Resultate wenig hilfreich sind, dann ist dem so.

Mr X

Die Behauptung ist gewagt, ehenkes.

Ja, ich weiss, dass man Tausende Warnungen bekommt, aber ich habe die Erfahrung gemacht, dass jede Warnung einen Bug bedeuten kann... d.h. in den 5000 Warnungen würde ich jetzt 5000 potentielle Bugs sehen...

Ein Teil der Meldungen kam daher, das es nicht mit C99 oder GCC-spezifischen Dingen klarkam (leider brach er daraufhin jedes Mal ab - ich musste jede Datei separat checken). Ein Problem, das cppcheck übrigens nicht hat. Dann waren die meisten Fehlermeldungen so formuliert, das man nicht verstand, was es von einem will. Oft beklagte er sich auch nur, weil man selbst einige Dinge definiert, die ein Anwendungsprogramm einfach aus der Standardlib beziehen würde (malloc, free, size_t, ...). Richtig war allerdings, das man keine Namen mit _ am Anfang verwenden sollte, da das für den Compiler "reserviert" ist.

abc.w

Ich habe mal splint über euren Quellcode laufen lassen, weiss jetzt nicht, welche Version, aufgerufen mit diesen Parametern:

splint -I /tmp/prettyos/trunk/Source/user/user_tools -I /tmp/prettyos/trunk/Source/kernel -booltype bool +nolib +gnuextensions +trytorecover blabla.c

und da sagt splint mehrmals "A memory leak has been detected" u. ä. oder Rückgabewerte von Funktionen unbenutzt, oder unsigned mit signed gemischt, oder untereinander nicht kompatible Datentypen gemischt u. ä. Hört sich alles nicht so gut an

Erhard Henkes

"A memory leak has been detected"

<--- das ist interessant. Wir kontrollieren ja bereits mit dem heap logger und überwachen auch den physischen Speicher auf leaks. Da ist mir momentan nix aufgefallen.