Rätsel
-
Huhu ihrs,
mein Professor hat mir ein Programm gezeigt, welches in einem Programmierwettbewerb dran kam.
Jetzt dacht ich, ich zeig das euch Profis mal

Ich selbst habe keinen blassen Schimmer was das Programm tut
... noch zu hoch für mich
#include <iostream> using namespace std; class B { public: B() {} virtual ~B() {} virtual int doIt() { return 1; } }; class D : public B { public: D() {} virtual ~D() {} virtual int doIt() { return 2; } }; class M : public B { public: M() {} virtual ~M() {} virtual int doIt() { return doItToo() * 5; } virtual int doItToo() { return 0; } }; int tryIt() { D d; void* dv = *((void**)&d); void* nv[3]; memcpy( (void*)nv, dv, 2*sizeof(void*) ); nv[2] = nv[1]; M m; nv[1] = (*((void***)&m)) [1]; *((void**)&d) = (void*)nv; typedef int (D::*DM) (); DM dm = (DM) &B::doIt; return (d.*dm) (); } int main() { cout << "Ergebnis: " << tryIt(); system("pause>nul"); return 0; }- Man musste herausfinden was das Programm tut.
- Man musste nicht herausfinden was die Ausgabe des Programmes ist.Wer lust hat kann ja mal rumrätseln,
und wer nicht, der nicht
Achja... der Professor meinte noch es hätte kein Wettbewerb-Teilnehmer hinbekommen.
MFG Dweb
-
WTF?
Also wenn schon obfuscation, dann richtig.
Wobei hier wohl das grösste Rätsel ist, ob das auch Standardkonformer Code ist und somit die Aufgabe überhaupt Sinn macht.
- Was es macht kannst du ja mal auf ein paar Implementierungen testen und mit dem Debugger verfolgen.. Dann weisst dus.
-
Es ist nicht standardkonform und es wird doof im vtable rumgepatcht.
Draufzukommen was das Ding *genau* tut sollte überhaupt kein Problem sein, bloss soweit interessiert es mich nun wirklich nicht.
-
Stürzt auch schön ab.

-
also bei mir kommt 22 raus

-
Is doch ziemlich langweilig... Und noch unsinniger.

-
hustbaer schrieb:
[...] und es wird doof im vtable rumgepatcht.
Oder auch nicht, je nach Implementierung.
-
Gustl schrieb:
also bei mir kommt 22 raus

Bei mir 10.

-
Also ich hoffe mal, dass die Aufgabe unter dem Gedanken von Standardkonformität gestellt wurde. (und warum man hie und da doch darauf achten sollte..)
-
Gibts dazu auch eine Erläuterung online?
Oder kann eventuell jemand was dazu sagen, warum das (nicht) Standardkonform ist? Und was meint Ihr genau mit Implementierungen?
-
Standard gibts hier als draft:
http://www.open-std.org/jtc1/sc22/wg21/
-
Bei mir gibt das Programm eine 10 aus ^^
-

laut Prof müsste das korrekte Ergebnis 10 sein..
obwohl ich 0 auch schon als Ergebnis gesehen hatte.
Und er meinte noch, dass da die VTable verfälscht wird wie schon geschrieben.
-
Was für ein Schwachsinn ist das denn bitte? Was für ein Ekliger mix.. deinen Lehrer sollte man Steinigen.
-
Hmmm, bei mir fehlten da noch
#include <cstdlib> #include <cstring>Und dann kam folgender Output:
$ ./main_1 *** glibc detected *** ./main_1: munmap_chunk(): invalid pointer: 0x00007fff55148380 *** ======= Backtrace: ========= /lib/libc.so.6[0x7f0a4c4a8948] ./main_1(__gxx_personality_v0+0x3cc)[0x400cfc] ./main_1(__gxx_personality_v0+0x214)[0x400b44] ./main_1(__gxx_personality_v0+0x286)[0x400bb6] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f0a4c452486] ./main_1(__gxx_personality_v0+0x49)[0x400979] ======= Memory map: ======== 00400000-00402000 r-xp 00000000 08:12 8819281 /home/user/Programmieren/C++/tests/c-plusplus-forum_de/235568/main_1 00601000-00602000 r--p 00001000 08:12 8819281 /home/user/Programmieren/C++/tests/c-plusplus-forum_de/235568/main_1 00602000-00603000 rw-p 00002000 08:12 8819281 /home/user/Programmieren/C++/tests/c-plusplus-forum_de/235568/main_1 00603000-00624000 rw-p 00603000 00:00 0 [heap] 7f0a4c434000-7f0a4c57f000 r-xp 00000000 08:11 344801 /lib64/libc-2.8.so 7f0a4c57f000-7f0a4c77e000 ---p 0014b000 08:11 344801 /lib64/libc-2.8.so 7f0a4c77e000-7f0a4c782000 r--p 0014a000 08:11 344801 /lib64/libc-2.8.so 7f0a4c782000-7f0a4c783000 rw-p 0014e000 08:11 344801 /lib64/libc-2.8.so 7f0a4c783000-7f0a4c788000 rw-p 7f0a4c783000 00:00 0 7f0a4c788000-7f0a4c79e000 r-xp 00000000 08:11 5342349 /lib64/libgcc_s.so.1 7f0a4c79e000-7f0a4c99d000 ---p 00016000 08:11 5342349 /lib64/libgcc_s.so.1 7f0a4c99d000-7f0a4c99e000 r--p 00015000 08:11 5342349 /lib64/libgcc_s.so.1 7f0a4c99e000-7f0a4c99f000 rw-p 00016000 08:11 5342349 /lib64/libgcc_s.so.1 7f0a4c99f000-7f0a4ca21000 r-xp 00000000 08:11 344524 /lib64/libm-2.8.so 7f0a4ca21000-7f0a4cc20000 ---p 00082000 08:11 344524 /lib64/libm-2.8.so 7f0a4cc20000-7f0a4cc21000 r--p 00081000 08:11 344524 /lib64/libm-2.8.so 7f0a4cc21000-7f0a4cc22000 rw-p 00082000 08:11 344524 /lib64/libm-2.8.so 7f0a4cc22000-7f0a4cd11000 r-xp 00000000 08:11 5440223 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.3/libstdc++.so.6.0.10 7f0a4cd11000-7f0a4cf11000 ---p 000ef000 08:11 5440223 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.3/libstdc++.so.6.0.10 7f0a4cf11000-7f0a4cf18000 r--p 000ef000 08:11 5440223 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.3/libstdc++.so.6.0.10 7f0a4cf18000-7f0a4cf1a000 rw-p 000f6000 08:11 5440223 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.3/libstdc++.so.6.0.10 7f0a4cf1a000-7f0a4cf2d000 rw-p 7f0a4cf1a000 00:00 0 7f0a4cf2d000-7f0a4cf49000 r-xp 00000000 08:11 344800 /lib64/ld-2.8.so 7f0a4d10e000-7f0a4d111000 rw-p 7f0a4d10e000 00:00 0 7f0a4d147000-7f0a4d149000 rw-p 7f0a4d147000 00:00 0 7f0a4d149000-7f0a4d14a000 r--p 0001c000 08:11 344800 /lib64/ld-2.8.so 7f0a4d14a000-7f0a4d14b000 rw-p 0001d000 08:11 344800 /lib64/ld-2.8.so 7fff55135000-7fff5514b000 rw-p 7ffffffe9000 00:00 0 [stack] 7fff55188000-7fff55189000 r-xp 7fff55188000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] AbgebrochenGCC-4.3.3 auf nem 64-Bit Gentoo.