Werner Mahr <[EMAIL PROTECTED]> writes:
> Am Montag, 11. April 2005 01:01 schrieb Nico Jochens:
>
>> entschuldige das ich versucht habe zu helfen (siehe andere Mail von
>> dir). Ich habe da wahrscheinlich unrecht und vielleicht C mit der
>> bash verwechselt, k.A. Da ich aber eh nicht so viel Ahnung vom
>> programmieren habe, finde ich es sehr nett von dir das du mir und
>> allen anderen Programmieranf�ngern es soo einfach erkl�rt hast...und
>> mit so viel Aussagekraft...bist du Politiker?
>
> Mal ein bisschen anschaulicher (falls ich ihn richtig verstanden habe)
>
> #include "1.h"
> a=b+c;
>
> Nur ein Ausschitt, aber reicht zu zeigen. F�r alle nicht Programmierer,
> das include kopiert einfach den Inhalt der angegeben Datei an diese
> Stelle.
>
> In 1.h steht jetzt irgendwas in der Art:
>
> b=6;
> c=7;
>
> Am Ende diese Datei steht jetzt aber kein Newline oder �hnliches.
> Wenn der genannte Pr�prozessor fertig ist, sieht dein Quelltext in etwa
> so aus:
>
> b=6;
> c=7;a=b+c;
>
> In diesem Beispiel w�rde das sogar funktionieren, da das Ende der
> Anweisung jeweils durch ein Semikolon gekenzeichnet wird. Es gibt
> allerdings auch Konstrikte ohne Semikolon am Ende (w�rde jetzt
> wahrschienlich zu weit f�hren, ist ja auch nur ein Beispiel), und dann
> h�ttest du zumindest eine schwer zu findenden Bug eingebaut.
Ich hatte doch schon das Schlagwort Makrodefinition erw�hnt.
a.h:
/* Ohne Newline am Ende */
#define blah 5
a.c:
#include "a.h"
int x=2; /* hier kriegen wir jetzt eigentlich #define blah 5x=2; */
int main() {
...
}
So, das kannst du jetzt mit gcc -E a.c testen, und, quelle surprise,
es wird wider die Logik trotzdem das vom Entwickler vermutlich
Erhoffte herauskommen. Und zwar weil der gcc Pr�prozessor smart genug
ist hier ein Newline einzuf�gen.
Fakt ist aber, da� der Pr�prozessor komplette Zeilen inklusive Newline
prozessiert, aus dem Source File entfernt und ggf. mit ihrem Ergebnis
ersetzt. D.h. gcc macht eigentlich mehr als er sollte, und sagt
einfach nochmal Bescheid.
Gruss, Bruno.
