Weiterentwicklung von PrettyOS



  • Mr X schrieb:

    Codestil oder Sprachstandards (Siehe anderer Thread)

    Was für ein Quatsch.

    Als ich hier - berechtigte - Zweifel an C99 angemeldet habe, hat man mich wohl als Troll missverstanden und kommentarlos meine Beiträge gelöscht.

    Das war auch bei den anderen Thread so, in dem ich die Stdlib von Pretty OS kritisiert habe.

    Anscheinend sind ernstgemeinte Ratschläge hier gänzlich unerwünscht.

    Das Problem an eurem "Coding-Style" ist, dass ...

    1. /* Solche Kommentare */ unerwünscht sind. Das ist ein gewaltiger Lapsus.
      2. CamelCase und unter_striche wild gemischt werden -> entweder - oder
      3. 0 statt NULL. Schon das lässt, wie ich schon mehrmals im Chat und hier im Forum mitgeteilt habe, tief blicken, wie es mit euren C-Kenntnissen steht (ihr verwechselt wohl C mit C++)

    Problem Nr. 3 ist wohl das übelste, weil es eben nur C99 konform ist, und gegen alle anderen Standards geht. 0 ist eben nicht NULL.

    Vielleicht hättet ihr C vor C++ lernen sollen. So können solche eklatanten Fehler garnicht passieren.

    So jetzt ists raus, euer Coding-Style ist in einigen Punkten nicht standardkonform. Das ist eine schlechte Grundlage.

    Ach ja: Nein, dieser Beitrag ist kein Troll-Beitrag. Er ist ernstgemeint.
    Ihr braucht ihn nicht zu löschen.
    Manchmal fühlt man sich hier wie im Kindergarten. Jede Kritik wird beleidigt gelöscht. 🙄



  • coding-style verbessern! schrieb:

    Das Problem an eurem "Coding-Style" ist, dass ...

    1. /* Solche Kommentare */ unerwünscht sind. Das ist ein gewaltiger Lapsus.
      2. CamelCase und unter_striche wild gemischt werden -> entweder - oder
      3. 0 statt NULL. Schon das lässt, wie ich schon mehrmals im Chat und hier im Forum mitgeteilt habe, tief blicken, wie es mit euren C-Kenntnissen steht (ihr verwechselt wohl C mit C++)

    Problem Nr. 3 ist wohl das übelste, weil es eben nur C99 konform ist, und gegen alle anderen Standards geht. 0 ist eben nicht NULL.

    Zu 1: Ob man nun diese Form der Kommentare bevorzugt oder nicht ist wohl jedem selbst ueberlassen. Die meisten Kommentare sind nunmal einzeilig, und da reicht durchaus ein // - zumindest in C99. Und auch wenn du es nicht magst, benutzen wir C99. Ist halt so. Da nachtraeglich was zu aendern waere sinnlos.

    Zu 2: Du verstehst den Sinn dahinter wohl nicht. camelCase ist die allgemeine Bezeichnungsregel fuer die Funktionen und Variablen. Die underscores sind nur fuer "Namespaces" vorgesehen. Alle HDD-Funktionen beispielsweise, die als Interface gedacht sind, beginnen dann halt mit hdd_.

    Zu 3: Es kompiliert und fertig. Und es ist auch C89-konform, unabhaengig davon, was dein GCC meckert. 0 ist eine standardkonforme Nullpointer constant, da kannst du drehen und wenden, was du willst. Steht gleichermassen in C89 und C99. Und selbst wenn es nur in C99 stuende, wuerde das nichts aendern. Nur weil du kein C99 magst, heisst das nicht, dass es keine Leute geben kann, die es moegen. Wir - besser gesagt die, die schon eher dabei waren, ich bin ja erst dazugestossen - haben uns/haben sich nunmal fuer C99 entschieden und das wird sich auf absehbare Zeit nicht aendern. Und wenn es sich aendert, dann sicher nicht zu C89 zurueck. Eher noch zu C++.

    BTW, deine Beitraege wurden nicht geloescht, oder du meinst nicht die, an die ich denke. Erhard (?) hats nur rausgesplittet, weils mit dem Styleguide weniger zu tun hatte. http://www.c-plusplus.net/forum/315527-full



  • Blödsinn. Da wurde nichts gelöscht, sondern hierher verschoben: http://www.c-plusplus.net/forum/315527
    Im Styleguide-Thread hatte das nichts verloren.

    Ich gehe auch nur sehr ungerne noch ein letztes Mal auf den Schwachsinn ein, den du die ganze Zeit von dir gibst:

    1. /* Solche Kommentare */ unerwünscht sind. Das ist ein gewaltiger Lapsus.

    Is klar... Wie wäre es damit, die Styleguide erstmal zu lesen, bevor Du sie kritisierst? Kleine Hilfe, ein Zitat aus selbiger: "Kommentare sind bei einzeiligen Kommentaren mit "//" einzuleiten." Da steht nichts davon, dass // generell verboten ist. Warum aber //-Kommentare grundsätzlich einen Vorteil haben, kann ich dir auch gerne erklären: Sie stören //-Kommentare nicht, d.h. man kann letztere dann weiterhin problemlos nutzen, um für Tests, etc., Codepartien auszukommentieren.

    2. CamelCase und unter_striche wild gemischt werden -> entweder - oder

    Eine Begründung für diese Mischung ist sogar mitgeliefert. Darum ist die Mischung schon gleich gar nicht "wild". Aber für Begründungen bist Du nicht zu haben, das kennen wir schon.

    3. 0 statt NULL. Schon das lässt, wie ich schon mehrmals im Chat und hier im Forum mitgeteilt habe, tief blicken, wie es mit euren C-Kenntnissen steht (ihr verwechselt wohl C mit C++)

    Offensichtlich hast Du noch immer keinen Blick in den C-Standard (welchen auch immer) geworfen und dir angeschaut, wie NULL beschrieben wird.

    Solange du jedenfalls dich nicht darum scherst, was dir geantwortet wird, und dir nichtmal die Mühe machst, zu Recherchieren, bevor du rumjammerst, kann von "berechtigt", "ernstgemeint", "Ratschlag" wirklich nicht reden.



  • Mr X schrieb:

    Offensichtlich hast Du noch immer keinen Blick in den C-Standard (welchen auch immer) geworfen und dir angeschaut, wie NULL beschrieben wird.

    Ich habe jetzt schon mehrmals geschrieben, NULL ist als symbolische Konstante auf einen Zeiger auf 0 definiert.

    #define NULL ((void *) /* <-- Zeiger */ 0)
    

    und nicht

    #define NULL 0
    


  • Ich habe jetzt schon mehrmals geschrieben, NULL ist als symbolische Konstante auf einen Zeiger auf 0 definiert.

    Und ich habe dir schon mehrfach gesagt, dass es so nicht im Standard (C89, C99, C11, such dir was aus) steht.



  • Mr X schrieb:

    Und mal generell: Mir ist völlig unverständlich, wieso hier ständig irgendwelche Metadiskussionen über Codestil oder Sprachstandards (Siehe anderer Thread) geführt werden müssen.

    Ihr habt die Registrierungspflicht aufgehoben, ganz einfach.



  • coding-style verbessern! schrieb:

    3. 0 statt NULL. Schon das lässt, wie ich schon mehrmals im Chat und hier im Forum mitgeteilt habe, tief blicken, wie es mit euren C-Kenntnissen steht (ihr verwechselt wohl C mit C++)

    Problem Nr. 3 ist wohl das übelste, weil es eben nur C99 konform ist, und gegen alle anderen Standards geht. 0 ist eben nicht NULL.

    Gnihihihihihi.

    Zuerst mal ist es absolute Selbstgeißelung, irgendwas vor C99 zu benutzen, zumal inzwischen schon C11 draußen ist.

    Zweitens, apropos C11: „gegen alle anderen Standards“ – du meinst, gegen C89 und C90, wobei C90 exakt das gleiche wie C89 ist. Es gibt neben C99 und C89/C90 noch einen dritten Standard, eben C11. Ergo geht das überhaupt nicht „gegen alle anderen Standards“, sondern nur gegen alle, die älter als 14 Jahre sind. In deiner Theorie. Die falsch ist, wie du durch tatsächliches Nachschlagen im Standard bemerkt hättest.

    Ergo drittens: Boah, Junge, guck doch mal in den Standard, bevor du rumtrollst.
    WP hat Links zu zwei verschiedenen Drafts, einer vom Mai[1] und einer vom November[2] 1988. In dem vom Mai steht unter Abschnitt 3.2.2.3 “Conversions: Other operands: Pointers” folgendes:

    An integral constant expression with the value 0, or such an expression cast to type void * , is called a null pointer constant.

    In dem vom November steht unter Abschnitt 4.1.5 “Common definitions – <stddef.h>” dann das hier:

    NULL can be defined as any null pointer constant. Thus existing code can retain definitions of NULL as 0 or 0L, but an implementation may choose to define it as (void *)0; […]

    Beides nennt also explizit sowohl einen Integer mit dem Wert 0 als auch (void *)0 als gültige null pointer constants.

    Der Vollständigkeit halber noch die (zugegebenermaßen viel deutlichere) Aussage aus C99 und C11 (6.3.2.3 – “Conversions: Other operands: Pointers”):

    An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.

    Lies in Zukunft den Standard, bevor du andere darüber belehrst.

    Und hör endlich mit C89 auf. Das ist tot und gehört vergraben.

    [1]http://flash-gordon.me.uk/ansi.c.txt
    [2]https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0BxVCLS4f8Sg5NWZmM2NjZWEtYmExMS00Y2EzLWE3ZTMtNzFmYjYwYzBiOTIw&hl=en_US

    PS: Und bevor jemand meckert, dass das nur Drafts sind und nicht der Standard selbst – ich hab erstens das Geld nicht, mir den echten Standard bei der ISO zu bestellen (C11 bspw. kostet 238 CHF), zweitens unterscheidet sich der letzte Draft eh praktisch nie vom fertigen Standard (es hat einen Grund, warum die Aussage in “Conversions: Other operands: Pointers” in C89, C99 und C11 praktisch wortwörtlich übereinstimmt) und drittens hat die ISO C89/C90 inzwischen sogar wieder zurückgezogen, weil C99 und C11 draußen sind (welch Überraschung!).


  • Mod

    Es war uns klar, dass es hier zu solchen "unbelehrbaren" Diskussionen kommen wird, wenn wir die Reg-Pflicht aufheben. Mit solchen divergierenden Threads können wir inzwischen gut leben. Das gehört zu einer solchen Community dazu. Übrigens lassen sich sich im chat solche Kontroversen besser austragen.

    @XanClic: Vielen Dank für die umfangreiche Zusammenfassung des aktuellen Zustandes.

    Zur finalen Verwirrung setze ich noch diesen Link dazu:
    http://openbook.galileocomputing.de/c_von_a_bis_z/014_c_dyn_speicherverwaltung_003.htm



  • Wer Bücher von Jürgen Wolf verlinkt, disqualifiziert sich wohl selbst. (Siehe auch: http://www.c-plusplus.net/forum/272350)


  • Mod

    Ich wollte nur aufzeigen, was zu diesem Thema alles "offiziell" durch die Suchmaschinen geistert. Daher ist eine kontroverse Diskussion hierzu kein Wunder. 😉



  • Leute wie " coding-style verbessern! ", die immer brav den "Standard" runterbeten kann man sowieso vergessen.

    Ob man nun 0 oder NULL verwendet, ist doch egal. Ich finde 0 schöner. Jemand anderer sieht das anders. Kümmert euch lieber um interessante Dinge im OS und nicht darum, ob ihr nun 0 oder NULL verwendet.
    Letztlich ist C ein Werkzeug, um ein Ziel zu erreichen. Man soll das Werkzeug beherrschen, aber hauptsächlich sollte man sich mit der zu bewältigenden Aufgabe beschäftigen.


  • Mod

    hauptsächlich sollte man sich mit der zu bewältigenden Aufgabe beschäftigen.

    Klar, machen wir! 😉


Anmelden zum Antworten