|
Anzeige
|
IOCC Contest
Gast
#2622765
Versteht jemand folgenden code? http://www.ioccc.org/2004/vik2.c o_O Ich krieg den weder compiliert noch versteh ich den zusammenhang mit c nicht... Features ======== The program implements an 11-bit ALU in the pre-processor. <--- o_O http://www.ioccc.org/2004/vik2.hint Kann wer ansatzweise erklären was da wie defined wird? Confused schrieb: > Versteht jemand folgenden code? Den kann man nicht verstehen, sonst hätte er nicht beim IOCCC gewonnen. :-) Der Trick dabei ist, dass der Präprozessor neue Präprozessor- anweisungen für den zweiten Lauf generiert. Da dort dann gleich noch die eigene Datei wiederholt inkludiert wird (mit Conditionals), wird das natürlich um so verwirrender. Schau dir einfach mal die Zwischenergebnisse an. Wenn du das letzte Zwischenergebnis mal von allem Ballast befreist, dann kann man zumindest erkennen, wie der tatsächlich generierte C-Code aussieht:
Das
steht dabei übrigens bereits unmittelbar in vik2.c drin. ;)
Gast
#2624904
Jörg Wunsch schrieb: > int main() > { > printf( > "%d" > "\n" > , > 1 > + > 1 > ) > ; > printf( > "%d" > "\n" > , > 1 > | 2 > ) > ; Es steht jedoch: pri\ ntf( "%d" "\n" , 1 G # \ inc\ lud\ e<s\ tdi\ o.h> int\ ma\ in() mit all den \ usw. also kein korrekter C code. Aber wenn wir oben anfangen Zeile 1: #define O \ <--- ok kann man machen ersetze O mit \ Zeile 2: #ifdef <---- ??? ja ifdef was?? Mein compiler meckert da (aus gutem grund) was ifdef was?? usw. Wie hast du eigentlich nur den preprocessor drübergelassen? Es ist nicht wirklich ungewöhnlich, dass Beiträge vom IOCCC sich nicht auf jedem Compiler übersetzen lassen. Des öfteren wurden da auch schon mal Eigenheiten vom Compiler bzw. Command Line Switches ausgenutzt, um auf einem spezifischen System compilierbar zu sein. Nimm den IOCCC als das, was er ist: Ein Sammelsurium an Kuriositäten und erfreu dich daran. Für irgendwelche wie auch immer geartete Lernzwecke ist der IOCCC mit 100% Sicherheit nicht zu gebrauchen. Höchstens als abschreckendes Beispiel, was man mit viel gutem Willen im Extremfall alles treiben kann. Aber selbst da muss man sagen: Selbst für diesen Zweck sind die Beispiele für die Katz, weil man derartigen Code in freier Wildbahn nicht antrifft. Confused schrieb: > # \ > inc\ > lud\ > e<s\ > tdi\ > o.h> > int\ > ma\ > in() > mit all den \ usw. also kein korrekter C code. Ich mag mich täuschen, aber der Einsatz des Continuation Characters beschränkt sich IMHO nicht nur auf den Präprozessor. Von daher: das ist gültig.
Gast
#2624922
Confused schrieb: > Zeile 1: #define O \ <--- ok kann man machen ersetze O mit \ Nein, das ist nicht die Wirkung. Stichwort: multiline define
Gast
#2624929
Ist mir schon klar, dass das ganze einen mehr akademischen Wert hat als wirklich praxisrelevant zu sein. Dennoch interessiert mich die Funktionsweise, da ich die C Syntax kenne und schon mal ifdef mit nix keinen sinn macht. Oder ja wäre ja nach dem define mit nix wärs dann true :D
Gast
#2624933
max schrieb: > Confused schrieb: >> Zeile 1: #define O \ <--- ok kann man machen ersetze O mit \ > > Nein, das ist nicht die Wirkung. Stichwort: multiline define Dann machts ja noch weniger sinn (hab ichs richtig verstanden: \ ist indikator, das define auf der nächsten Zeile weiter geht?). Dann haben wir: #define O #ifdef #define Q #undef #define C #define #define G #else #define D #ifndef #define l #include FNAME #define I #endif Confused schrieb: > max schrieb: >> Confused schrieb: >>> Zeile 1: #define O \ <--- ok kann man machen ersetze O mit \ >> >> Nein, das ist nicht die Wirkung. Stichwort: multiline define > > Dann machts ja noch weniger sinn (hab ichs richtig verstanden: \ ist > indikator, das define auf der nächsten Zeile weiter geht?). Nicht nur #define. \ mit einem Zeilenvorschub direkt dahinter ist der 'Continuation Character' und wirkt so, als ob es hier keinen Zeilenumbruch gäbe. > Dann haben wir: > > #define O #ifdef > #define Q #undef > #define C #define > #define G #else > #define D #ifndef > #define l #include FNAME > #define I #endif ok. Und das wendest du jetzt mal auf
an. Was kommt da raus?
Gast
#2624944
Richtig. Und dann weiter mit den kommenden Zeilen. Wende die nun bekannten #define an.
Gast
#2624986
Confused schrieb: > Ist mir schon klar, dass das ganze einen mehr akademischen Wert hat als > wirklich praxisrelevant zu sein. Nein, das hat auch keinerlei akademischen Wert - das ist eine Spielerei für Geeks (positiv gemeint), aber nicht mehr und schon gar nicht akademisch.
Gast
#2625020
Karl Heinz Buchegger schrieb: > Was kommt da raus? #ifdef i #ifdef o #ifdef c #undef c #endif /* ... */ 1 #else # \ inc\ lud\ e<s\ tdi\ o.h> int\ ma\ in() #define _N #define _h #define _M #undef i { l + 1 ) ; #include FNAME } #endif #endif --- korrekt? [1000 Zeilen generierter Code inline im Posting ist zuviel, habe ich eingekürzt. Jörg] Confused schrieb: > Wie hast du eigentlich nur den preprocessor drübergelassen? gcc -E Du hast noch nicht verstanden, dass der Prozess mehrstufig ist. Der erste Präprozessorlauf erzeugt einen C-Code, den man wiederum durch den Präprozessor schicken muss. Zusammen mit den vielen (absichtlich verwirrenden) #ifdef und #undef etc. ergibt sich dann ein ellenlanger Spaghetti, von dem nur ein kleiner Teil effektiv genutzt wird. Antwort schreiben |
Anzeige
|
