C-Standardbibliothek; C89 vs C99
-
Mr X schrieb:
ja, weil du erkennst, dass c99 kein guter weg ist
C89-Code ist einfach eklig, weil die Sprache fast nichts kann. Der C99-Standard ist auch unschön, weil er sich in mancher Hinsicht von C++ wegbewegt.
wer c++ programmieren will, der muss c++ programmieren und nicht c.
wenn du sagst, dass c89 eklig ist, dann sagst du gleichzeitig, dass c eklig ist.
c ist halt so.
der ordner heißt übrigens "stdlibc".
und alle dateien haben die endung .c oder .h.
-
Jonas OSDever schrieb:
Das kannst du sagen, wenn wir pointer mit 0xD34DB3EF vergleichen. Wir vergleichen aber mit einer standardkonformen Null pointer constant.
ja, aber eben nach dem c99 standard, der von vielen compilern (fast) nicht unterstützt wird.
programmiert ihr nicht unter windows? ich nehme mal an, ihr benutzt den microsoft c++ kompiler, der einen c-modus hat... aber einen c89 modus
der ms-compiler unterstützt garkein c99.
tja, wie es aussieht, habt ihr aufs falsche pferd gesetzt.
außerdem habt ihr anscheinend nicht ganz verstanden, worauf es beim c-programmieren ankommt.
wie der code am ende aussieht, interessiert keinen. meistens gilt: desto kürzer, desto besser.
for schleifen sind hier völlig unnütz.
-
Gut, dass die Unregs hier jetzt mitdiskutieren können.
*popcornhol*
-
c89 rulez schrieb:
Jonas OSDever schrieb:
Das kannst du sagen, wenn wir pointer mit 0xD34DB3EF vergleichen. Wir vergleichen aber mit einer standardkonformen Null pointer constant.
ja, aber eben nach dem c99 standard, der von vielen compilern (fast) nicht unterstützt wird.
Nope, steht genauso im C89-Standard
c89 rulez schrieb:
wie der code am ende aussieht, interessiert keinen. meistens gilt: desto kürzer, desto besser.
Weil NULL ja auch kuerzer als 0 ist...
MFK schrieb:
*popcornhol*
Spagetti mit Pilzsauce machen sich bei so einer Dis(s)kussion auch vorzueglich
-
programmiert ihr nicht unter windows? ich nehme mal an, ihr benutzt den microsoft c++ kompiler, der einen c-modus hat... aber einen c89 modus
Nein, den benutzen wir nicht (für PrettyOS), weil er für die Erzeugung von ELF- oder rohen Binärdateien einfach schlecht geeignet ist.
ja, aber eben nach dem c99 standard, der von vielen compilern (fast) nicht unterstützt wird.
Meine Güte. Jetzt lies erstmal jede einzelne Antwort von mir nochmal, bevor Du wieder was schreibst. Gerne auch zusätzlich noch einen C-Standard deiner Wahl.
der ordner heißt übrigens "stdlibc".
und alle dateien haben die endung .c oder .h.
Wirf ruhig mal einen Blick in übliche Implementationen von C und C++-Standardbibliotheken (z.B. MSVC, die habe ich hier vorliegen). Die C++-Header, die den C-Standard wrappen, machen einfach ein #include <stdio.h> (im Falle von <cstdio>) und verpacken das Ergebnis dann noch ggf. in namespaces. D.h. C++-spezifische Abweichungen von C sind im Header der C-Standardbibliothek enthalten!
-
MFK schrieb:
Gut, dass die Unregs hier jetzt mitdiskutieren können.
*popcornhol*
der umstand, dass ich nicht registriert bin, sagt nichts über die qualität meiner beiträge aus.
Mr X, du sagst, dass C89 ekelig ist. Das ist halt so. Die guten C-Quellcodes sind meistens verschachtelt und schwer lesbar, dadurch zeigt aber der Programmierer, dass er weiß was er tut, und dass er weiß, wie man code gut optimiert.
-
Die guten C-Quellcodes sind meistens verschachtelt und schwer lesbar, dadurch zeigt aber der Programmierer, dass er weiß was er tut, und dass er weiß, wie man code gut optimiert.
Ja sicher... Und das ist auch voll kompatibel mit dem Anspruch von PrettyOS, einsteigerfreundlichen Code zu haben.
-
Jonas OSDever schrieb:
c89 rulez schrieb:
Jonas OSDever schrieb:
Das kannst du sagen, wenn wir pointer mit 0xD34DB3EF vergleichen. Wir vergleichen aber mit einer standardkonformen Null pointer constant.
ja, aber eben nach dem c99 standard, der von vielen compilern (fast) nicht unterstützt wird.
Nope, steht genauso im C89-Standard
der gcc kompiliert standardmäßig im c89-modus und gibt warnungen.
das reicht mir. wenn ein compilerhersteller, der wahrscheinlich den originalen c-standard gelesen hat, meint, dass ich das so machen soll, dann mach ich das auch so. ich habe übrigens noch kein lehrbuch gesehen, in dem empfohlen wird, pointer mit 0 zu prüfen.c89 rulez schrieb:
wie der code am ende aussieht, interessiert keinen. meistens gilt: desto kürzer, desto besser.
Weil NULL ja auch kuerzer als 0 ist...
du drehst mir die worte im mund herum. du weißt doch hoffentlich, wie das gemeint war, oder? wenn ich einen 100zeiligen code schreibe, den man genausogut in 20 zeilen schreiben könnte, ist die 20 zeilen methode meist die bessere.
wie sagte schon goethe: "Nichts ist schlimmer als eine tätige Unwissenheit."
-
Mr X schrieb:
Die guten C-Quellcodes sind meistens verschachtelt und schwer lesbar, dadurch zeigt aber der Programmierer, dass er weiß was er tut, und dass er weiß, wie man code gut optimiert.
Ja sicher... Und das ist auch voll kompatibel mit dem Anspruch von PrettyOS, einsteigerfreundlichen Code zu haben.
anfänger haben bei der betriebssystem-programmierung nix verloren.
die sollen erstmal richtig c lernen.
-
anfänger haben bei der betriebssystem-programmierung nix verloren.
Ich rede nicht von C-Anfängern. Ich rede von Anfängern in der OS-Programmierung. Auch erfahrene Entwickler haben da erstmal besseres zu tun, als irgendwelche maximalkomplizierten Konstrukte auseinanderzudröseln, wenn sie sich zum ersten Mal mit Betriebssystemcode befassen.