kennt sich jemand mit C aus?

[Christoph Zurnieden]

Hi,

for(int i=0;i<100;i++);

[...]

Ey, ein Semikolon hinter einer for-Anweisung ist ja auch schon verdächtig.

Aber sehr schnell gemacht, da hinter fast jeder Zeile ein Semikolon steht. Da ensteht mit der Zeit ein gewisser Automatismus. Obiger Fehler ist auch teilweise schlecht zu sehen, da ein Semikolon am Zeilenende nicht auffällt. Es ist ja mehrheitlich durchaus in Ordnung und wenn doch nicht, wird ein Syntaxfehler produziert.

Auch wenn manche Programmierer -mich selbst eingeschlossen- bei kurzen Loops manchmal alles in die Klammer packen. Dann wäre das okay.
Aber das hat meiner Ansicht nach nichts mit der Frage zu tun, ob eine Klammer am Zeilenende oder am Zeilenanfang stehen sollte.

Weil

for(int i=0;i<100;i++){;

kein Problem dargestellt hätte?

Aber ich werde einen Teufel tun, und mich auf eine Diskussion über Style einlassen. Bis auf diese eine Stelle wüßte ich auch weiter nichts, was über reine Geschmacksache hinausginge. Und "Einer ist Keiner" wie's so schön heißt, oder? :-)

Halt, nein, einen gibt's noch: man sollte bei Vergleichen mit Konstanten eigentlich die Konstante voranstellen
if(INTEGER_CONSTANT == variable)
Damit der typische Fehler
if(INTEGER_CONSTANT = variable)
eine Syntaxfehler ergibt. Aber daran kann ich mich dann wieder nicht gewöhnen ;-)

So funktioniert das nur auf einem PC o.ä., wenn Du auf "exotischere" Platformen umschwenkst kannst Du damit ganz gewaltig auf die Schnauze fallen.

Ich habe auch schon Embedded-Anwendungen auf diversen µC's gebastelt. Ha, da war ein int noch 8bit wert!

Ich rede von exotischen Architekturen. So ein 8-Bit-PIC von Conrad-Elektronik ist noch lange nicht exotisch ;-)
(Viele Maschinenbauaer haben in den Anfangstagen ihr eigenes Süppchen gekocht. Wenn man da auf eine PDP-11 als Embeded Prozessor stieß, war man noch glücklich dran. Da wurden Sachen entwickelt, das glaubst Du noch nicht einmal wenn Du's siehst ;-)

Ein Byte ist nicht überall 8 Bit lang, ein int nicht überall 32 Bit, aber ein char entspricht einem Byte und ein Byte ist groß genug ein Zeichen der jeweiligen Umgebung zu halten:

Selbstverständlich. Der Auszug aus dem Standard, den du zitierst, sagt allerdings nichts zur char/int-Verwandtschaft.

Da gibt es auch außer dem Hinweis auf die "integer promotion" (man kann mit char Typen Integerberechnungen ausführen) nichts zu.
Ich möchte aber diese Stelle - denn sie ist genau so gut, wie jede andere - auch dazu nutzen folgendes festzustellen: der C-Standard ist keineswegs perfekt, der hat auch seine Macken, ist aber im großem und ganzem in Ordnung und gebrauchsfähig.
Es ist also durchaus möglich, das er hier eine seiner Macken zeigt.

Ich kenne den Standard zwar nicht in der Theorie, aber aus der Anwendung.

Aus den Implementationen? Also als Microsoft-C, Borland-C, Gnu-C usw?

Und da sind nun mal char und int nichts weiter als zwei Varianten eines Integer-Grundtyps und somit zuweisungskompatibel.

Da der Standard das aber nicht festgelegt hat, ist das nur implementationsabhängig. Würde ich kein sauberes Hemd dran aufhängen wollen, kann bei der nächsten Version schon anders sein und dann liegt das gute Linnen im Dreck.

Nur mit dem Vorzeichen muss man dann und wann aufpassen. Das kann man aber recht gut vermeiden, indem man -soweit möglich- unsigned-Typen verwendet. Oft kann man das sogar ohne Einschränkung machen.

Das haut aber meistens gegen die Deklarationen der Lib-C. Aber diese Deklarationen sollten auch mal so langsam angepaßt werden, das ist einfach nicht mehr zeitgemäß, nur mit char zu arbeiten. ASCII alleine reicht irgendwie nicht so wirklich ;-)

Sag ich doch: Wenn ein Vorzeichen ins Spiel kommt, muss man aufpassen. Aber das Vorzeichen ist eh nur Illusion: Ein gesetztes MSB,

Das Vorzeichen muß nicht unbedingt im MSB sein, das kann auch woanders und sogar gleich etwas ganz anderes sein.
Aber wie Du schon ganz richtig sagst...

das nur bei ein paar wenigen Operationen (>>-Operator, Ausgabe über eine der printf-Funktionen) überhaupt eine besondere Rolle spielt.

... soviele Fallen gibt es da nicht und die sind auch alle bekannt.

Und wer schreibt auch heutzutage noch für 'ne alte Vax oder 'ne PDP-11 o.ä. ;-)

Dein Auszug aus dem Standard beschreibt nur, was der Compiler daraus machen soll, wenn der Programmierer seine Variablen *nicht* explizit initialisiert.

Ich hatte eigentlich _beides_ kopiert?
Ah, Mißverständnis, wie ich hier unten sehe, sorry.

Ich meine mich aber zu erinnern, dass es irgendwo eine Regel gibt, nach der strukturierte Datentypen (und dazu gehören ja auch Arrays) mit Nullwerten aufgefüllt werden, wenn sie *nur teilweise* initialisiert werden, so wie z.B.
unsigned long pp[40] = { 2, 1, 0 };

Dazu habe ich nichts gefunden, zumindest nichts deutliches, scheint implementationsabhängig zu sein.

char string[ANZ+1];
alleine reicht dafür nicht.

Das hab ich auch nicht gesagt. Diese Zeile ist ja auch nur eine Deklaration, keine Initialisierung.

Wer beckmessert jetzt hier? ;-)

Deshalb sollte der Anfänger Standard-C lernen und kein Windows-C, DOS-C, Linux-C oder was weiß ich alles.

Richtig. Die Spezialisierung auf eine bestimmte Plattform kommt erfahrungsgemäß von ganz allein im Lauf der Zeit.

Na, ich hoffe doch nicht!
Lieber nix von allem wissen, als alles über nix ;-)

so short

Christoph Zurnieden