Code Styleguide
-
Man findet bei der Suche nach stdbool.h:
http://www.koders.com/c/fidDF4818DD265741F8A74455FC281F0C1CBA35EB47.aspx
#ifndef _STDBOOL_H #define _STDBOOL_H /* believe it or not but the Single Unix Specification actually * specifies this header, see * http://www.opengroup.org/onlinepubs/007904975/basedefs/stdbool.h.html */ #define bool _Bool #define true 1 #define false 0 #define __bool_true_false_are_defined 1 #endifhttp://gel.sourceforge.net/examples/stdbool_8h-source.php
00029 #ifndef _STDBOOL_H_ 00030 #define _STDBOOL_H_ 00031 00032 #define __bool_true_false_are_defined 1 00033 00034 #ifndef __cplusplus 00035 00036 #define false 0 00037 #define true 1 00038 00039 #define bool _Bool 00040 #if __STDC_VERSION__ < 199901L && __GNUC__ < 3 00041 typedef int _Bool; 00042 #endif 00043 00044 #endif /* !__cplusplus */ 00045 00046 #endif /* !_STDBOOL_H_ */
-
Erhard Henkes schrieb:
while(1){/* */}wirkt halt irgendwie seltsam.
Ja, aber nur, weil while kein Funktionsaufruf ist, deshalb gehört ein Leerzeichen zwischen while und (1):
while (1) { /* Do nothing, infinite loop */ }
-
abc.w schrieb:
Erhard Henkes schrieb:
while(1){/* */}wirkt halt irgendwie seltsam.
Ja, aber nur, weil while kein Funktionsaufruf ist, deshalb gehört ein Leerzeichen zwischen while und (1):
while (1) { /* Do nothing, infinite loop */ }while(1) ist sowieso schlecher Stil. Manche Compiler beschweren sich darüber mit "Condition always true". Besser: for(;;)
-
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
-
Besser: for( ;; )
"Das ist Geschmacksache", sagte der Affe, als er in die Seife biss.
Das Thema ist allerdings TRUE, true, 1 oder nicht 0.
-
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.
-
Bin gerade dabei ...
Das Thema ist true, 1 oder nicht 0.
-
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.
-
general bacardi schrieb:
`typedef enum {false, true} bool;
...
bool b = true;
`
Übrigens, bei solchen Sachen ist sizeof(bool) == sizeof(int)?
-
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 1Am Unklarsten ist mir die Rolle von "char" bezüglich int8_t bzw. uint8_t.
-
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.
-
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
-
char* exception_messages[] = { "Division By Zero", "Debug", ...?
Also char für Texte und (u)int8_t nur, wenn das Ding als Zahl betrachtet wird.
-
@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.
-
Ich habe einen ersten Entwurf unseres Styleguide als Diskussionsbasis erstellt:
http://www.henkessoft.de/OS_Dev/Downloads/PrettyOS_Styleguide_C.zip
-
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.
-
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
-
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.
-
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).
-
warum kein "int"? Was meinst Du damit?
Das x und i den gleichen Typ haben sollen?