IOCC Contest

[Confused (Gast)]

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?

[Jörg W. (dl8dtl) (Moderator)]

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:

int main()
{
printf(
"%d"
"\n"
,
1
+
1
)
;
printf(
"%d"
"\n"
,
1
| 2
)
;

Das

printf("%d" "\n", 1

steht dabei übrigens bereits unmittelbar in vik2.c drin. ;)

[Confused (Gast)]

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?

[Karl H. (kbuchegg)]

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.

[Karl H. (kbuchegg)]

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.

[max (Gast)]

Confused schrieb:
> Zeile 1: #define O \ <--- ok kann man machen ersetze O mit \

Nein, das ist nicht die Wirkung. Stichwort: multiline define

[Confused (Gast)]

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

[Confused (Gast)]

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

[Karl H. (kbuchegg)]

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

O  i
O  o
O  c
Q  c
I
O  d
Q  d
I
O  e
Q  e
I
O  f
Q  f
I
O  g
Q  g
I
O  h
Q  h
I
O  Z
Q  Z
I
O  j
Q  j
I
O  k
Q  k
I
O  m
Q  m
I
....

an. Was kommt da raus?

[max (Gast)]

Richtig.
Und dann weiter mit den kommenden Zeilen. Wende die nun bekannten 
#define an.

[GTA (Gast)]

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.

[Confused (Gast)]

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]

[Jörg W. (dl8dtl) (Moderator)]

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.