Weiterentwicklung von PrettyOS



  • Erhard Henkes schrieb:

    sadasdd schrieb:

    wie wäre es, als Lern - OS alles etwas mehr zu dokumentieren?

    Völlig richtig. Es gibt bereits Anfänge, z.B. die Beschreibung von Paging und Heap: http://www.c-plusplus.net/forum/261588-4
    (Werte sind nicht mehr aktuell, das müsste man aktualisieren, aber Prinzip gilt noch)
    Was wir bisher nicht wollten: Unmengen an Kommentaren im Code, vor allem vor Funktionen.
    Ich denke ein Anfang könnte ein Doku-Thread sein, in dem die einzelnen Module in ihrer Wirkungsweise mit Links auf entsprechende Grundlagen, falls vorhanden, beschrieben sind.

    Es gibt auch eine Ressourcen-Linkliste für OSDev von mir:
    http://henkessoft.de/OS_Dev/OSDEV Ressourcen.html

    ich kenn es eh, wenn ich entwickle hab ich meist recht wenig lust darüber eine doku zu schreiben. schliesslich kann man die zeit sinnvoller nutzen - z.b. zum programmieren 😉
    trotzdem wäre gerade das hier ein thema, wo doku sehr wichtig ist!
    wenn jemand etwas implementiert, reicht es ja, ein paar worte darüber zu verlieren - z.b. eben in einem thread hier im forum. dinge wie memory management, prozess management, interrupts, u.ä. sind nämlich nicht unbedingt selbsterklärend. sprich: es reicht nicht, den source durchzulesen, nein, man muss auch die dahinterliegende theorie etwas verstehen. andererseits reicht aber bereits wenig text aus, um viele unklarheiten zu beseitigen.

    mein tipp: sucht euch eine zentrale stelle für eure doku! denn teile der doku sind auf deiner HP, andere teile mit dem source mitgeliefert, und teilweise verstecken sich auch gute infos in den untiefen des c++ forums.
    macht einen eigenen thread auf, in welchem die entwickler kurz stellung nehmen zu ihren entwicklungen. fragen dürfen dann in einem anderen thread gestellt werden, sodass der doku thread nicht zugespamt wird.



  • mein tipp: sucht euch eine zentrale stelle für eure doku! denn teile der doku sind auf deiner HP, andere teile mit dem source mitgeliefert, und teilweise verstecken sich auch gute infos in den untiefen des c++ forums.
    macht einen eigenen thread auf, in welchem die entwickler kurz stellung nehmen zu ihren entwicklungen. fragen dürfen dann in einem anderen thread gestellt werden, sodass der doku thread nicht zugespamt wird.

    Ich denke, der richtige Platz für weiterführende Dokumentation ist beim Code, aber nicht im Code (zuviel Text). Also im Repository in /documentation.


  • Mod

    Also im Repository in /documentation.

    Wie wird das gesehen? Ist das ausreichend zugänglich oder muss es direkt im Forum sein?



  • Um das noch etwas weiter zu begründen: Ich halte es für grundfalsch, ein Forum zum Informations-Ablageplatz zu machen, weil es dafür ungeeignet ist. Beiträge verschwinden in der Versenkung oder gehen in einer Fülle von Antworten unter, das liegt in der Natur der Sache. Außerdem kann nur ein Moderator oder man selbst an eigenen Beiträgen rumeditieren, was höchst problematisch ist, da Unsinn so oft auf lange Zeit erhalten bleibt. Ein Forum ist eben eine Diskussionsplatform.



  • Erhard Henkes schrieb:

    Wie könnte die Community besser kommunizieren und/oder zusammenarbeiten?

    Git(hub)

    user/user_tools/userlib_cpp.cpp

    #if (__GNUC__ >= 4 && __GNUC_MINOR__ >= 7)
    

    Juhu, bei GCC 5.0 kracht es plötzlich.
    Es müsste natürlich so heißen:

    #if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 7))
    

    Hat es eigentlich irgendeinen Nutzen, dass viele Dateien mit der Lizenz oben und unten zugemüllt sind?

    Kellerautomat schrieb:

    Mr X schrieb:

    •Tabs zum Einruecken

    Da hat jeder seine Vorlieben. Ich bevorzuge zwar auch Tabs, aber: Es zu ändern wäre bescheuert, dann käme der nächste, der lieber Leerzeichen mag und will es wieder zurückändern. Wenn man einmal einen Stil gewählt hat, sollte man ihn nicht wieder umwerfen. Mal davon abgesehen, dass solche großflächigen Stiländerungen Funktionen wie svn-blame nutzlos machen (bzw. schwächen).

    Das hat mit Vorlieben nichts zu tun. Wer Spaces benutzt, versteht den Unterschied zwischen Ausrichten und Einruecken nicht. Tabs zum Einruecken, Spaces zum Ausrichten.

    👍 Spaces zum Einrücken sollten verboten werden. Allerdings könnte man dann nicht mehr über die kreativen Begründungen lachen.

    Alle Achtung übrigens für das Projekt.
    Es ist wirklich interessant in einem überschaubaren Betriebssystem zu lesen.
    Ich musste auch nur eine Anpassung vornehmen ( size_t für operator new ) zum Kompilieren.

    Wie könnte ich denn Änderungen einbringen ohne sofort ein "Mitglied" werden zu müssen?


  • Mod

    Wie könnte ich denn Änderungen einbringen ohne sofort ein "Mitglied" werden zu müssen?

    Das geht unkompliziert. Änderungsvorschläge an MrX (patch oder anders) senden, er ist regelmäßig im IRC chat zu finden.



  • Erhard Henkes schrieb:

    Wie könnte ich denn Änderungen einbringen ohne sofort ein "Mitglied" werden zu müssen?

    Das geht unkompliziert. Änderungsvorschläge an MrX (patch oder anders) senden, er ist regelmäßig im IRC chat zu finden.

    Ok. Wie wäre es, wenn man erstmal diese Coderegeln abschafft? Ob ich jetzt Tabs oder Spaces, oder bei jeder geschweiften Klammer auf { eine neue Zeile anfange, ist dem Compiler egal.

    Mit solchen Coding-Vorschriften hab ich bisher keine guten Erfahrungen gemacht.



  • Nein, Projekte sollten einen einheitlich Codestil einbehalten.



  • cooky451 schrieb:

    Nein, Projekte sollten einen einheitlich Codestil einbehalten.

    du meinst wohl sowas:

    char *char_pointer;
    if( char_pointer == 0)
    {
        // ...
    }
    

    mhh? 😕



  • Ok. Wie wäre es, wenn man erstmal diese Coderegeln abschafft? Ob ich jetzt Tabs oder Spaces, oder bei jeder geschweiften Klammer auf { eine neue Zeile anfange, ist dem Compiler egal.

    Uns ist es aber nicht egal, und wir wollen unseren eigenen Code noch verstehen können. Und eine einheitliche Formatierung unterstützt bei menschlichen Lesern das Verständnis. Stell dir mal Code vollständig ohne Einrückungen vor...

    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. Die Styleguide ist so festgelegt, wie sie ist, und ohne praktischen Grund werden wir die nicht grundlegend ändern (und abschaffen übrigens auch nicht).


  • Mod

    @Subjective-C: Ja, was soll man da sagen? Klar ist Freiheit und Individualität eine feine Sache. Bei einem gemeinsamen Projekt ergeben klare Regeln jedoch Sinn, ansonsten haben wir ständig überflüssige Diskussionen und Korrekturen von A nach B während des Projektes, und keiner hat recht. Hier besitzen leider Praktikabilität und Frieden im Team höhere Priorität als die individuelle Gestaltungsfreiheit. Aus dem gleichen Grund gibt es wohl auch Werkrichtlinien, Haus- und Schulordnungen. Hier werden wir nicht nachgeben. 😉



  • 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)


Anmelden zum Antworten