4. Code Styleguide

Code Styleguide

  • G

    Erhard Henkes schrieb:

    C99 hat noch kein bool und true und false?

    Doch: http://en.wikipedia.org/wiki/Stdbool.h 🕶

    abc.w schrieb:

    Wozu überhaupt ein boolean, es gibt 0 und ungleich 0 und so schreibt man es am Besten explizit hin...

    Die Intention wird dadurch deutlich, dass es sich um Wahrheitswerte handelt.

    0
  • A

    general bacardi schrieb:

    abc.w schrieb:

    Wozu überhaupt ein boolean, es gibt 0 und ungleich 0 und so schreibt man es am Besten explizit hin...

    Die Intention wird dadurch deutlich, dass es sich um Wahrheitswerte handelt.

    Informatikermärchen 😉

    0
  • E
    Mod

    Also, wenn ich in ckernel.c

    while(TRUE){/*  */}

    gegen

    while(true){/*  */}

    austausche, erhalte ich folgende Fehlermeldung:

    ckernel.c:332: error: 'true' undeclared

    Füge ich

    typedef enum {false, true} bool;

    in os.h ein, so läuft das brav durch. Damit können wir "true" und "false" (analog C99 bzw. C++) verwenden. Das ist modern. Daher plädiere ich dafür. Jeder weiß, dass false 0 und true 1 bedeutet.

    Bezüglich: "ungleich 0"
    Wo finde ich dies in einer Definition? TRUE oder true ist doch in der Regel gleich "1" definiert?

    while(1){/*  */}

    wirkt halt irgendwie seltsam. 😃

    0
  • V

    Erhard Henkes schrieb:

    Wo finde ich dies in einer Definition? TRUE oder true ist doch in der Regel gleich "1" definiert?

    Ich meine mich zu erinnern, daß true als !false definiert ist. Ob das true==1 wird, ist egal.

    0
  • G

    Erhard Henkes schrieb:

    Bezüglich: "ungleich 0"
    Wo finde ich dies in einer Definition?

    Das steht sicherlich im C-Standard

    if (a)  /* Wenn a ungleich 0 wird verzweigt */
{
  ...
}

    TRUE oder true ist doch in der Regel gleich "1" definiert?

    Nein, true ist das Gegenteil von false. Es gibt nur die beiden. 1 ist eine Zahl und Zahlen gibt es sehr viele. 🤡

    0
  • E
    Mod

    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

#endif

    http://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_ */
    0
  • A

    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 */
}

    😉

    0
  • G

    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(;;)

    0
  • A

    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

    0
  • E
    Mod

    Besser: for( ;; )

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

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

    0
  • G

    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.

    0
  • E
    Mod

    Bin gerade dabei ...

    Das Thema ist true, 1 oder nicht 0. 🙂

    0
  • G

    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.

    0
  • A

    general bacardi schrieb:

    `typedef enum {false, true} bool;

    ...

    bool b = true;

    `

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

    0
  • E
    Mod

    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.

    0
  • V

    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.

    0
  • E
    Mod

    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

    0
  • V
     

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

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

    0
  • E
    Mod

    @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.

    0
  • E
    Mod

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

    0
Anmelden zum Antworten