Code Styleguide

abc.w

general bacardi schrieb:

while(1) ist sowieso schlecher Stil. Manche Compiler beschweren sich darüber mit "Condition always true". Besser: for(;;)

Stimmt. Der gcc sagt hier aber nichts, man muss es wahrscheinlich explizit einschalten. Der Sun Compiler hat da gleich eine andere Warnung ausgegeben, siehe http://www.c-plusplus.net/forum/viewtopic-var-t-is-252358.html (PrettyOS 107er Version)

cc -O -m32 -xc99 -Bstatic -Iinclude -c -o ckernel.o ckernel.c
"ckernel.c", line 209: warning: statement not reached

Erhard Henkes

Besser: for( ;; )

"Das ist Geschmacksache", sagte der Affe, als er in die Seife biss.

Das Thema ist allerdings TRUE, true, 1 oder nicht 0.

general bacardi

Erhard Henkes schrieb:

Das Thema ist allerdings TRUE, true, 1 oder nicht 0.

Verabschiede Dich von TRUE. Nur Makros schreibt man gross. Enums normalerweise nicht.

Erhard Henkes

Bin gerade dabei ...

Das Thema ist true, 1 oder nicht 0.

general bacardi

Erhard Henkes schrieb:

Bin gerade dabei ...
Das Thema ist true, 1 oder nicht 0.

Wenn Du C-kompatibel sein willst, nimm 0 für false und alles andere für true. Ansonsten ist es egal. Du kannst es definieren, wie Du möchtest.

abc.w

general bacardi schrieb:

`typedef enum {false, true} bool;

...

bool b = true;

`

Übrigens, bei solchen Sachen ist sizeof(bool) == sizeof(int)?

Erhard Henkes

Ich denke, dass unter Verwendung des bei C99 eingebauten Typs _Bool folgendes in os.h sinnvoll ist:

typedef unsigned int         size_t;

typedef unsigned long long   uint64_t;
typedef unsigned long        uint32_t;
typedef unsigned short       uint16_t;
typedef unsigned char        uint8_t;

typedef signed long long     int64_t;
typedef signed long          int32_t;
typedef signed short         int16_t;
typedef signed char          int8_t;

#define bool _Bool
#define true 1
#define false 0
#define __bool_true_false_are_defined 1

Am Unklarsten ist mir die Rolle von "char" bezüglich int8_t bzw. uint8_t.

volkard

Erhard Henkes schrieb:

Am Unklarsten ist mir die Rolle von "char" bezüglich int8_t bzw. uint8_t.

char dürfte ein eigener typ sein, wobei das aber nicht beobachtet werden kann. er verhält sich genau wie int8_t oder wie uint8_t, je nach maschine. das verhalten kann mit compilerschalter -funsigned-char oder -fsigned-char überschrieben werden.

Erhard Henkes

compilerschalter -funsigned-char oder -fsigned-char

Danke für den Tipp! Ich habe mich innerlich nämlich auf -fsigned-char eingerichtet. Hoffe, das ist ok. das hier hatte mich etwas irritiert, als ich den Cast (int8_t*) einbauen musste:

int8_t* exception_messages[] =
{
    (int8_t*)"Division By Zero",        (int8_t*)"Debug",   ...

Ist das überflüssig, wenn man -fsigned-char verwendet?

Ich habe ja typedef signed char int8_t; in os.h

volkard

char* exception_messages[] =
{
    "Division By Zero",        "Debug",   ...

?
Also char für Texte und (u)int8_t nur, wenn das Ding als Zahl betrachtet wird.

Erhard Henkes

@Volkard: Ja, das ist zwar nicht wirklich logisch, erscheint aber praktisch vernünftig. Ich werde das wieder umstellen, damit wir möglichst portabel bleiben.

Also char für Texte und (u)int8_t nur, wenn das Ding als Zahl betrachtet wird.

char wird für Texte (Strings) ab Rev. 18 (SVN) wieder Stück für Stück eingebaut.

Erhard Henkes

Ich habe einen ersten Entwurf unseres Styleguide als Diskussionsbasis erstellt:
http://www.henkessoft.de/OS_Dev/Downloads/PrettyOS_Styleguide_C.zip

Erhard Henkes

Aus dem IRC: <MrX> Ich schlage die Einführung eines Punktes bezüglich Deklaration im Schleifenkopf vor.

Wir sind gerade dabei, alle for(...) auf c99 umzustellen, mit Deklaration und Scope der Laufvariablen nur innerhalb der Schleife.

abc.w

Erhard Henkes schrieb:

Wir sind gerade dabei, alle for(...) auf c99 umzustellen, mit Deklaration und Scope der Laufvariablen nur innerhalb der Schleife.

Das ist alles ok, solange die Schleifenvariable nicht außerhalb des Schleifenkörpers benutzt wird oder irgendeine andere "überschattet" (hier kann man sich mit dem -Wshadow absichern)

Und "for(...)" ist kein Funktionsaufruf und da gehört ein Leerzeichen hin "for (...)"

Auch bei Ausdrücken: Nicht "for(i=0;i<max;++i)", sondern "for (i = 0; i < max; ++i)"

"Coding Style"... ein heikles Thema

Mr X

Ich bin gegen ein Leerzeichen hinter for. Ich bin für diese Schreibweise:
for(int i = 0; i < x; ++i)
Wshadow wäre aber in der Tat nützlich. Das sollten wir einführen.

abc.w

Mr X schrieb:

Ich bin gegen ein Leerzeichen hinter for. Ich bin für diese Schreibweise:
for(int i = 0; i < x; ++i)

Musst aber zugeben, dass for kein Funktionsaufruf ist(nein,Quatsch,ist nut ein Scherz;))

Nach Möglichkeit auch kein int(sonst sollte x auch ein int sein).

Mr X

warum kein "int"? Was meinst Du damit?

Das x und i den gleichen Typ haben sollen?

abc.w

Mr X schrieb:

warum kein "int"? Was meinst Du damit?

Das x und i den gleichen Typ haben sollen?

size_t sollte normalerwise verwendet werden. x und i sollten den gleichen Typ vom Vorzeichen her haben. Entweder beide vorzeichenbehaftet oder beide ohne Vorzeichen.

Mr X

Das hängt 1. Davon ab, was man grad hochzählt und 2. ist das wichtigste ja wohl, das x und i den gleichen Typ, egal erstmal welchen, haben.

abc.w

Mr X schrieb:

Das hängt 1. Davon ab, was man grad hochzählt und 2. ist das wichtigste ja wohl, das x und i den gleichen Typ, egal erstmal welchen, haben.

Nach dem Tipp von Tobiking2 hier http://www.c-plusplus.net/forum/viewtopic-var-t-is-263735.html bezüglich "Optimization Reference Manual" von Intel, Kapitel "3.4.2.2 Optimizing for Macro-fusion", ist es wohl so, dass "unsigned" Datentypen "Macro-fusion", was immer man darunter versteht, ermöglichen. Es gibt in dem Kapitel auch ein Beispiel mit einer for-Schleife. Lesenswert.