Hallo Besucher, der Thread wurde 13k mal aufgerufen und enthält 93 Antworten

letzter Beitrag von Zirias/Excess am

C Frage ist folgendes zulässig?

    Zitat von ogd

    Weil ich gerade ein paar Bücher durchgehe und schon alle drei Varianten gesehen habe: Wie würdest du folgendes in C deklarieren?

    Ich persönlich ganz klar die erste Variante. Aber ist eine interessante Frage, da hier der Grundsatz "Deklaration sieht aus wie Verwendung" nicht greifen kann, const gibt es in der Verwendung nicht. Mein Argument, *const hier zusammenzuschreiben ist, dass es der Pointer ist, der unveränderlich wird.


    Variante zwei hat daher auch etwas für sich. Man könnte argumentieren, dass obwohl sich das const hier auf den Pointer bezieht, der Pointer immer noch zum Identifier der Variablen gehört. Diese Schreibweise habe ich jedenfalls auch schon gesehen, ich glaube aber die erste ist häufiger.


    Variante drei ist ganz klar die C++-Schule -- der Pointer als Teil des Typs.

    Zitat von ZeHa

    Ich fand Variante 3 immer am logischsten. Es ist ja eben kein char sondern ein char-Pointer, und der Name des char-Pointers ist name und nicht *name.

    Siehe weiter oben im Thread: Das ist die C++-Logik. Wird wie schon erwähnt unlogisch bei Mehrfachdeklarationen oder wenn man versucht, das Prinzip auf Arrays zu übertragen ;)


    Da es aber letztendlich eine Stilfrage ist gibt es nicht "die eine Wahrheit".

    Zitat von ZeHa

    Ich fand Variante 3 immer am logischsten. Es ist ja eben kein char sondern ein char-Pointer, und der Name des char-Pointers ist name und nicht *name.


    Im gedruckten Reference Manual vom WATCOM Compiler (Kennt den noch jemand oder nur dessen Erzeugnisse mit dem DOS4GW? :D )


    wurde es verständlich erklärt und auch die Schreibweise 3 favorisiert.



    Variante 2 -> Absolutes No-Go! Sieht aus wie Multiplikation und empfinde ich als genauso furchtbar wie die weitverbreitete Unsitte zum "plenken".

    Zitat von androSID

    Im gedruckten Reference Manual vom WATCOM Compiler [..] wurde es verständlich erklärt und auch die Schreibweise 3 favorisiert.

    Das ist ja auch ein C++ Compiler (nennt sich glaube ich C/C++, als sei das die gleiche Sprache) -- kein Wunder, dass man da den Stroustrup-Stil hernimmt :) Und klar gibt es eine Menge Leute, die diesen Stil auch in C übernommen haben. "Falsch" ist wie gesagt nichts. Warum es in meinen Augen aber unlogisch ist und ich daher lieber beim traditionellen C-Stil bleibe hatte ich oben erklärt ;)

    Zitat von androSID

    Variante 2 -> Absolutes No-Go! Sieht aus wie Multiplikation und empfinde ich als genauso furchtbar wie die weitverbreitete Unsitte zum "plenken".

    Auch eine Meinung :D Kann ich auch verstehen, mir gefällt es auch nicht so richtig. Ich vermute mal diejenigen, die es so schreiben, argumentieren ungefähr so wie ich oben überlegt habe...


    Zum Thema Stil gibt es in Sprachen, die keinen fest vorgeben, sowieso immer wieder ausschweifende Diskussionen. Es gibt beispielsweise den Stil, Rückgabewerte zu return grundsätzlich in Klammern zu schreiben. Finde ich persönlich absolut grauenhaft. Oder den Operanden zu sizeof in Klammern zu setzen (Da hat Linus Torvalds eine seiner berüchtigten "starken Meinungen", er meint sizeof sollte man sehen als sei es eine Funktion ... nunja). Mag ich persönlich auch nicht, die Klammern werden nur bei einem Typnamen geschrieben, denn da verlangt es der C-Standard, nicht aber bei einem Ausdruck ....

    Zitat von zrs1

    Das ist ja auch ein C++ Compiler (nennt sich glaube ich C/C++, als sei das die gleiche Sprache) -- kein Wunder, dass man da den Stroustrup-Stil hernimmt :) Und klar gibt es eine Menge Leute, die diesen Stil auch in C übernommen haben. "Falsch" ist wie gesagt nichts. Warum es in meinen Augen aber unlogisch ist und ich daher lieber beim traditionellen C-Stil bleibe hatte ich oben erklärt ;)


    Ist ein C++ Compiler nicht auch ein C Compiler? :bgdev


    Wie gesagt: Die meisten Projekte an denen ich beteiligt war waren entweder reines C++ oder eine Mischung aus C und C++... und in letzterem Fall die Coding Styles zu vermischen
    war/wäre der Lesbarkeit nicht dienlich.


    Aber über Coding-Styles zu debatieren ist genauso sinnlos, wie über Musik(geschmack) zu reden! Da hat jeder seine Meinung und hat auch immer
    eine (aus seiner Sicht!) logische Erklärung dafür... was auch bedeutet: Keiner wird seinen Stil ändern - außer er hat noch gar keinen.


    Nachtrag... in dem erwähnten Reference Manual war ein einleuchtendes Beispiel drin; zwecks lesbarkeit mal abgewandelt mit stdint.h Typen:


    C
    1. uint8_t num;
    2. const uint8_t* pNum;
    5. pNum = # // OK!
    6. *pNum = 1; // Not OK!
    C
    1. uint8_t num;
    2. const uint8_t* const pNum;
    5. pNum = # // Not OK!
    6. *pNum = 1; // Not OK!
    C
    1. uint8_t num;
    2. uint8_t* const pNum = # // OK!
    3. *pNum = 1; // OK!
    4. pNum++; // Not OK!



    Die Merkregel war: Rückwärts lesen:


    1. Fall -> Pointer auf konstanten uinteger8.
    2. Fall -> Konstanter Pointer auf konstanten uinteger8.
    3. Fall -> Konstanter Pointer auf uinteger8.

    Zitat von zrs1

    Oder den Operanden zu sizeof in Klammern zu setzen (Da hat Linus Torvalds eine seiner berüchtigten "starken Meinungen", er meint sizeof sollte man sehen als sei es eine Funktion ... nunja). Mag ich persönlich auch nicht, die Klammern werden nur bei einem Typnamen geschrieben, denn da verlangt es der C-Standard, nicht aber bei einem Ausdruck ....


    Ich verwende sizeof auch immer mit Klammern (aus Bequemlichkeit). Oder gibt es da auch Fallstricke, wie oben bei überflüssigen, expliziten casts?

    Zitat von androSID

    in dem erwähnten Reference Manual war ein einleuchtendes Beispiel drin; zwecks lesbarkeit mal abgewandelt mit stdint.h Typen:

    Also ich glaube das erklärt einfach nur, worauf sich ein const jeweils bezieht, und hat eher wenig damit zu tun, wohin der Asterisk in einer Pointer-Deklaration "gehört" ;)


    Zitat von ogd

    Ich verwende sizeof auch immer mit Klammern (aus Bequemlichkeit). Oder gibt es da auch Fallstricke, wie oben bei überflüssigen, expliziten casts?

    Nö, gibt es nicht, jedenfalls nicht direkt. Es gibt Fallstricke, wenn man Typnamen mit sizeof verwendet:
    int *foo = malloc(sizeof (int *));
    int *foo = malloc(sizeof *foo);
    So, jetzt habe ich gemerkt, dass ich ein long brauche. In welcher Version passiert es wohl eher, dass ich einen Bug einführe? ;)


    Ich schreibe persönlich keine Klammern für Ausdrücke als Operand von sizeof, weil ich dann auf einen Blick sehe, dass diese Verwendung unproblematisch ist, während ich bei Klammern (die ja nur mit Typnamen nötig sind) genauer hinschauen muss.


    Aber nein, einen Fallstrick würde ich das nicht nennen, es schadet sicher nichts, immer die Klammern zu schreiben. Der werte Herr Torvalds hält aber alles andere für falsch und dumm und wasweißichnicht ... ;)

    Zitat von zrs1

    Also ich glaube das erklärt einfach nur, worauf sich ein const jeweils bezieht, und hat eher wenig damit zu tun, wohin der Asterisk in einer Pointer-Deklaration "gehört" ;)

    Richtig... aber die Leserichtung war in vielen Fällen, die "Eselsbrücke": Kontanter Pointer auf Integer.
    Aber sei's drum: Deine Argumente überzeugen mich nicht und umgekehrt... insofern würde ich vorschlagen es einfach gut sein zu lassen.


    ogd: Ich stimme da mit Torvalds überein: Als Funktion sehen... daher Klammer.

    Zitat von androSID

    Aber Deine Argumente überzeugen mich nicht und umgekehrt

    Es wäre auch sinnlos, in einem (hauptsächlich) C++-Projekt plötzlich den typischen C Stil zu nutzen. Zwar hat C++ die grundlegende Grammatik der Sprache nicht geändert (deshalb sind die Punkte, wo der "C++-Stil" unlogisch wird, die gleichen wie in C), aber wenn alle Welt den gleichen Stil hernimmt sollte man das trotzdem tun.


    Ich hoffe hier aber, dass einige Leute, wenn sie wirklich C (und eben nicht C++) schreiben, den entsprechenden Stil wählen. Müssen tut keiner was, es sei denn im Team mit festgelegten Coding Guidelines ;)


    Zitat von androSID

    ogd: Ich stimme da mit Torvalds überein: Als Funktion sehen... daher Klammer.

    Blöd nur, dass es eben keine Funktion ist ;) Meistens merkt man den Unterschied als Programmierer nicht, trotzdem ist es manchmal wichtig zu wissen, dass es eben ein Operator ist. Ob man nun Klammern schreibt hat damit allerdings nicht direkt etwas zu tun...

    Wenn C mit C++ gemischt wird, sollte jederzeit klar sichtbar sein, in welchem Umfeld der aktuelle Code angesiedelt ist. Nicht überall ist der Unterschied zwischen C und C++ so schnell sichtbar wie bei static


    Bei sizeof bin ich auf der Klammerfraktion, weniger aufgrund der Frage ob's eine Funktion ist oder nicht, sondern wegen der Klarheit der Rangfolge in Verbindung mit weiterenn Operationen. Ja, es gibt eine Rangfolge der Operatoren, aber im Ernstfall tut eine Klammer zuviel weniger weh als eine zu wenig...

    Zitat

    Ich hoffe hier aber, dass einige Leute, wenn sie wirklich C (und eben nicht C++) schreiben, den entsprechenden Stil wählen. Müssen tut keiner was, es sei denn im Team mit festgelegten Coding Guidelines


    Eben genau das nicht! Sobald man eine "mal schnell" programmierte Komponente in ein größeres C++ Projekt einbringen soll/will,
    passt dann der Codingstyle nicht mehr. Daher gleich auf den Coding Style der Obermenge gehen.



    Keine muß - aber: Ich habe (außer bei eigenen Projekten) die letzten 25 Jahre immer mit verbindlichen Coding Guidelines gearbeitet
    oder sofern es meine Position im Projekt verlangte die Coding Guidelines mit ausgearbeitet.


    In den Fällen, wo ich die Softwareprojektleitung machen durfte, habe ich die Schnittstellen verbindlich festgelegt und es "unter der Haube" dem
    Programmierer überlassen - aber eher um Streit zu vermeiden. Interessanterweise waren es meistens die "alten Hasen", die dann immer
    mit Ihrem abgelutschten K&R Buch (und den uralten Schreibweisen) ankamen!
    Aber genau die sind dann meistens auch schon beim Thema Lambda functions, Templates oder sogar ausgestiegen... ("Neumodischer Mist... braucht keiner!")


    Zitat von Tale-X

    ...aber im Ernstfall tut eine Klammer zuviel weniger weh als eine zu wenig...

    Full ACK! (Zumal die meisten die Operator Precedence nicht auswendig im Kopf haben.

    Zitat von androSID

    Daher gleich auf den Coding Style der Obermenge gehen.

    C++ ist keine Obermenge von C, auch wenn sich dieses Gerücht äußerst hartnäckig hält.

    Zitat von androSID

    Interessanterweise waren es meistens die "alten Hasen", die dann immer
    mit Ihrem abgelutschten K&R Buch ankamen! Aber genau die sind dann meistens auch schon beim Thema Lambda functions, Templates oder sogar
    ausgestiegen...

    Noch ein Seitenhieb obendrauf als "Argumentverstärker"? K&R ist pre-standard C, das hat mit der Diskussion hier absolut nichts zu tun. Wer heute ernsthaft C verwendet, nimmt auch den aktuellen Standard her (bis vor kurzem C11, aber der Umstieg auf C18 hat sicher schon begonnen)

    Zitat von zrs1

    C++ ist keine Obermenge von C, auch wenn sich dieses Gerücht äußerst hartnäckig hält.


    Ich sehe es als Obermenge, weil ich C-Code problemlos in C++ integrieren kann... umgekehrt nicht.


    PS: Stroustrup sieht es in seinem Buch (wortwörtlich) auch so! Aber es bleibt Dir überlassen hier vom Erfinder der Sprache abzuweichen.