I will not go into details, but I stumbled upon a "textual user interface" for GNU GDB, the debugger for GNU GCC/G++ C/C++ compiler in Unix environments.
gdb file.cpp -tui
This was a major breakthrough, and then, as if TUI mode wasn't mind-bending enough, I found
gdb-dashboard, which is simply a matter of placing .gdbinit file into one's home directory (in Linux, it doesn't seem to work in Windows - WinGW gdb does not even support the -tui flag).
The file is written in Python, of all things. It's freaking stone cold MAGIC, is what it is.
This little discovery has rejuvenated me to the point where I was even motivated to figure out how to implement the same kind of "Debgging Dashboard" in Visual Studio when in Windows. I have ventured into the Dark Side.
It was simply a matter of firing up various windows from the Debug menu, things like Local, Assembly, Registers, Call Stack, etc ...
The strange thing is, I have been engrossed in Python because of all the associated computer algebra systems, and when I was accidentally introduced to Alexander Stepanov's work, I became curious about Standard Template Libraries in C++, which forced me to get my system environments set up for compiling and debugging C/C++ more effectively.
Now I am even interested in the assembly code and registers underneath the high-level code.
It is as though I am coming around full circle with a beginner's mind, but much more calm this time around. I plan on eventually finding a way around the 2^32 = 4294967296 limitation in my 1999 xfac code. I'm sure the way I set up my debugging environments will make the process more of a learning experience than a chore.
There may be a use for those arrays of prime numbers ... If I can just get past the 2^32 limitation. I knew back in 1999 when I was first exploring C and C++ that the data type long int was still a limit.
This is not my main motivation though. It's just kind of "symbolic" - very spiritual for me ... especially considering I was hacking away over the summer of 1999 with just Knuth's The Art of Computer Programming volume 1 / Fundamental Algorithms as my guide. It was a small section on prime numbers which was my guide for constructing the arrays of prime numbers. Unlike the short and elegant prime factorization scripts I use now, that old original attempt can actually tell me where each prime is located in the array of primes. It has potential. I have not forgotten about it. It's gone from 1.2 MB floppy diskette to CD's and now sits on a USB flashdrive with little changes along the way.
If I were to replace the long int data type with something else, or include a sophisticated library, I would then, after 16 years, rename it xfac2.
Like I said, that is not what is motivating me.
I have to credit Python, specifically it's libraries and the community of "scientists and mathematicians" who created NumPy (introducing arrays), SymPy (symbolic, not just numeric), z3Py, and, of course, Sage.
This all, somehow, made me interested in C/C++ again.
Imagine my delight when, just as I was jumping for joy upon realizing gdb had the TUI frontend, that someone had created gdb-dashboard (frontend for the gdb GNU debugger for C/C++), to see that it was written in Python.
It's all interconnected and, I dare say, quite "spiritual".
I say it is spiritual because I know that those who are interested in such things are equally esctatic about this. One thing to celebrate in this dismal swamp of misery is the spirit of community that the Open Source culture represents. Corporations and Universities do not have a monopoly on Knowledge and "Tech-gnosis".
To paraphrase Virginia Woolf, "Knowledge (she used the word, "Literature") is open to everybody. I refuse to allow you to turn me off the grass. Lock up your libraries if you like; but there is no gate, no lock, no bolt that you can set upon the freedom of my mind."
gdb-dashboardscreenshotAs I mentioned, an unexpected ramification of this frontend which is implemented in Linux, forced me to find a way to "Unixify" my interaction with Microsoft Visual Studio. Visual Studio has these capabilities also. It is just a matter of tracking them down and getting them to work.
It has been said that Microsoft Visual Studio does not support compiling single source files, but if one is patient, one can just keep a separate directory for one's little pet source files, then, when interacting with the Beast, Visual Studio, and I know this seems a bit "too much" just to compile a little code, it is what it is, create a New Project, select Win32 or even Visual C++, enter the path to the source code, and name the "Project"
.
Then, when specifying project settings, use Visual Studio, Project Type: Console. Do not select "Add support for ATL" or any other. Compile with F7 (or menu Build | Build Solution).
Myself, I prefer the Linux environment, with:
g++ -g xfac.cpp -o xfac
There is a way to compile with Microsoft Visual C++ from the command line:
cl xfac.cpp /EHsc /Zi
but you still need the Visual Studio development IDE for debugging ... but setting it up like the gdb-dashboard adds some "harmony" to the otherwise "hitting a fly with a sledge-hammer" feel of VS.
You never know, one day you might be interested.