Was mich bei Ansi C am meisten stört
-
SeppSchrot schrieb:
War sizeof(char) nicht als 1 festgeschrieben?
ja, 1 char
-
SeppSchrott
***********Ja
net
***Warum soll er denn tricksen? Nach Standard zumindest C99 ist // als Kommentar erlaubt, da brauch er nix tricksen.
-
TheTester schrieb:
Warum soll er denn tricksen? Nach Standard zumindest C99 ist // als Kommentar erlaubt, da brauch er nix tricksen.
auf den standard kann man sch... wenn man c-codes schreibt, die viele unterschiedliche c-compiler, auch älterer bauart, fressen sollen. da muss man den 'kleinsten gemeinsamen nenner' nehmen
-
Dann kann ja der Typ mit dem Uralt-Compiler tricksen. Oder, was noch einfacher wär, ein einfaches S&R, wenns keine Verschachtelungen gibt.
-
ISO/IEC 9899:1999, section 6.4.9, line 18 schrieb:
// comments were added for C99 due to their utility and widespread existing practice, especially in dual C and C++ translators.
-
Was ist eigentlich so schlimm an /* ... */?
-
Bashar: Du hast ein bisschen Code geschrieben mit einem Kommentar:
Code /* Kommentar wie der Algorithmus funktioniert */ denk dir hier einen komplizierten Algorithmus Code
Jetzt findest du einen besseren und kommentierst erstmal den alten aus, vielleicht brauchst du ihn ja noch:
/* Code /* Kommentar wie der Algorithmus funktioniert */ denk dir hier einen komplizierten Algorithmus Code */
Außerdem ist es mehr zu schreiben.
-
Gewöhnungssache, eigentlich kommentiert man mit
#if 0 Quelltext /* Kommentar */ Quelltext #endif
aus. Es gibt einige Editoren, die denn Text zw. dem '#if 0' und dem '#endif' auch gleich in Kommentarfarben hervorheben.
-
Daniel E. schrieb:
Gewöhnungssache, eigentlich kommentiert man mit
#if 0 Quelltext /* Kommentar */ Quelltext #endif
das ist aber kein ersatz für // eher für /* */
-
Soll auch kein Ersatz für // sein. Lies doch die letzten paar Postings nochmal
-
IMHO sind solche Syntaxkleinigkeiten unbedeutend.
Bedeutender finde ich (wenn wir jetzt rein von der Syntax ausgehen) dass mit Zeigern, Arrays und Funktionszeigern die Zeiger-Syntax einfach nicht tragbar ist.
Aber wenn das einzige was einem an einer Sprache stoert die Form der Kommentare ist, dann hat man fuer sich selbst wohl die ideale Sprache gefunden...
-
Viel affiger finde ich es, immer struct schreiben zu müssen.
Disclaimer: Das ist nicht das einzige, was mich an C stört und nicht als Hinweis zu nehmen, das C für mich die ideale Sprache ist, auch wenn es sich nach einer Kleinigkeit anhört.
-
Und wenn es wirklich gar nicht ohne // geht und man den Code portabel halten muss, hat man sich ja wohl ruckzuck einen Parser geschrieben, der // durch /* und am Ende der Zeile */ ersetzt.
Sofern der Editor nicht dahingehend erweiterbar sein sollte.So lässt man ihn einfach vor dem Release drüberlaufen.
-
Bashar schrieb:
Was ist eigentlich so schlimm an /* ... */?
Dass sie nicht nested sein dürfen...!
-
SeppSchrot schrieb:
Und wenn es wirklich gar nicht ohne // geht und man den Code portabel halten muss, hat man sich ja wohl ruckzuck einen Parser geschrieben, der // durch /* und am Ende der Zeile */ ersetzt.
Sofern der Editor nicht dahingehend erweiterbar sein sollte.So lässt man ihn einfach vor dem Release drüberlaufen.
Nein, das geht ja eben nicht, weil du diese Teile nicht schachteln kannst. Es gibt keinen Ersatz für // auch, das if( 0 ) ist Unsinn. Wenn du die Kommentare nicht hast, musst du dich ärgern.
-
Optimizer schrieb:
Es gibt keinen Ersatz für // auch, das if( 0 ) ist Unsinn.
Warum?
#if 0
ersetzt /*
und /* ersetzt //und #if 0 darf geschachtelt werden...
-
Er bezog sich dabei auf den (völlig unbrauchbaren) Vorschlag: #define // if(0)
-
Optimizer schrieb:
Viel affiger finde ich es, immer struct schreiben zu müssen.
typedef??
Und zum Thema Kommentare: Mein emacs fügt die Kommentare für einen region automatisch mit /* ... */ pro Zeile ein. Also kein Problem mit Kommentaren
-
DrGreenthumb schrieb:
Er bezog sich dabei auf den (völlig unbrauchbaren) Vorschlag: #define // if(0)
unbrauchbar? der ist sogar besser als //
damit kannste ganze {} - codeblöcke ausblenden. die eventuellen warnings des compilers von wegen "unreachable code" musste natürlich übersehen
-
kneifel schrieb:
Optimizer schrieb:
Viel affiger finde ich es, immer struct schreiben zu müssen.
typedef??
Ja? Soll ich für jedes struct ein typedef schreiben? Ist wohl nicht wirklich ernst zu nehmen, sorry.