Was mich bei Ansi C am meisten stört
-
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.
-
net schrieb:
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 übersehenEs geht aber nicht immer!
if( blubb ) { // Hack: Zum Test mal 0 genommen foo(0, bar, x); // variable, bar, x); }
Jetzt hast Ärger mit deinem if( 0 ) - define. /* / - define nützt dir auch nichts, weil das mit "richtigen" / */ nicht nesten kannst. Ist doch nicht so schwer einzusehen, dass du dir diese Funktionalität nicht selber schaffen kannst, oder?
-
net schrieb:
DrGreenthumb schrieb:
Er bezog sich dabei auf den (völlig unbrauchbaren) Vorschlag: #define // if(0)
unbrauchbar? der ist sogar besser als //
meinst du das jetzt ernst?? Wer wirklich so ein define baut, gehört geschlagen. So ein falsches // ist doch viel schlimmer als ein fehlendes.
Optimizer schrieb:
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.
'türlich ist das Ernst zu nehmen.
typedef struct Point {
int x, y;
} Point;Is ja nun nicht so die Welt...
-
Man hätte die C Variante mit den Nützlichkeiten aus C++ ohne Objektorientierung (also quasi C99) einfach C+ nennen sollen.
Dann gäbs den Ärger nicht.
-
Optimizer schrieb:
Viel affiger finde ich es, immer struct schreiben zu müssen.
Dann nimm doch BCPL, da gibt's kein "struct".
A := B!3 // Zugriff auf Element 4 von B. // oder MANIFEST $( DATENSATZ.WURST = 0 DATENSATZ.KAESE = 1 DATENSATZ.BUTTER = 2 $) A := D!DATENSATZ.BUTTER
-
net schrieb:
DrGreenthumb schrieb:
Er bezog sich dabei auf den (völlig unbrauchbaren) Vorschlag: #define // if(0)
unbrauchbar? der ist sogar besser als //
Unbrauchbar. Schau dir mal die "Phases of translation" an. In C und C++ werden in der dritten Phase Kommentare ersetzt. defines aber erst in der vierten. Aus dem #define // if(0) wird so ein #define und das ist kein gültiger #define-Ausdruck, da der identifier fehlt.