Weird Code Analysis
using gdb debugger as a tool for the exploration, analysis, and better understanding of oddly sublime codeLovecraft mythos connection to programming and mathematics; limits of reason: the dependencies on the abstractions of symbolic algebra may represent the structural limitations of our ability to perceive. Nonetheless, even within the limits of reason, some intellectual phenomena can appear alien, that is, very weird looking, like something authored by a species of cerebral, super-sentient octopus. (multiple types of intelligent octopi, what do we really know of the beings of the deep sea and deep space?)
Even within our own species, in a single generation, the syntax, grammar, the whole of the foundations of the taken-for-granted universe of abstractions cannot be absorbed by the individual human organism, the single human animal. Some code is especially strange or elegant.
Even within the Limits of Reason, in a subset of {the limits of reason}, such as the modern C++ programming language, the abstract edifice enforced by the authors of the compilers becomes an unfathomable "intellectual contraption" requiring continual learning and flexibility, that is, there is a dynamic. Code evolves beyond its own lifetime … mutating sequences of bits.
Some code is especially weird, but I find the term "especially" before the term "weird" to be unnecessary. The terror of not being able to fathom all the knowledge and technology we are exposed to may be considered "mentally-induced terror." This is a terror Lovecraft experienced personally. I have to walk carefully along the razor's edge paths of mental disciplines, to be extremely forgiving of myself for my vast ignorance.
My idea, as an aid to self-study, is to use cheap art-sketch notebooks to "draw code" - not in the order it is presented in the source code files, but as it is explored in a debugging session in gdb, setting breakpoints, stepping through, stepping into ... EXPLORING, analyzing, and most surely better understanding when using such powerful queries as "whatis"
This has been very helpful in exploring programs that use templates to implement the generic programming-style. I wish to break it down into "slow motion snapshots" so that I might spark an ever so small amount of interest in the "craft." It is ok to feel "terrified" enough to make use of the debugger in creative and interactively playful ways.
_________________________________________________________
Technical PreliminariesDownload the script
dbinit_stl_views-1.03.txt. Save as STL_views.conf.
Add a ~/.gdbinit file to home directory if you don't have one (
DOT gdbinit)
Add a line:
source /path_to/STL_views.conf to your ~/.gdbinit.
or you can just copy and paste entire STL_views.conf at the end of .gdbinit in ~/
Restart gdb
This adds several commands (pvector, plist, pmap etc.) to gdb whose function is to print the elements of STL. It also adds print pretty
Note that you can open a separate terminal/console, type tty to get number /dev/pts
Then, from inside gdb, type: dashboard -output /dev/pts/number
Then, when code runs in debugger, output is displayed in the other console.
_____________________________________________________________
Inspiration for Thought Experiment 0:
Indexer<T> index(T& t) { return Indexer<T>(t); }I altered zipper_code.cpp so as to test using user-defined type, Fraction.
The
fraction.cpp and
fraction.h are same as one's at github/Gorticide/PPP_LAB/ch20.
g++ -g -Wall fraction.cpp zipper_code.cpp -o zit
./zit
gdb zit
break main
break 53 // Indexer<T> index(T& t) { return Indexer<T>(t); }
break 28 // constructor for class iterator: iterator(inner_iterator it): _pos(0), _it(it) {}
dashboard -output /dev/pts/3
run
continue
step
whatis p
whatis p.first
whatis p.second
whatis set_Q
[ ... and so on ... ]