…that not everyone knows what I know. Knowledge is hard won, but somehow after you know something it seems completely obvious. Even though it is not.
Some guy using my xll library kept pestering me to debug his code. It was clear to me he needed to invest more time learning C++. One dirty secret about open source software is that most people only complain about the problems they encounter. I am fine with that as long as they are pointing out shortcomings in my code. Not so much when they think I’m a free resource to fix their crappy code that has nothing to do with my library.
I’ve been lucky to have a couple of people that actually provided code I could use, but that seems to be as rare as rocking horse shit. I learned a lesson today from the guy that was calling me names for telling him he might not want to use my library.
C++ is hard. Really hard. But some fascinating things are going on in that world now. Some of the smartest people in the world have been making it easier to use. Google Bjarne Stroustrup and just listen to what he has to say. The world needs more people like him.
I’m teaching a course that uses C++ and it is still the case that people have trouble with just compiling and running a program. It is the price you pay for using a language that was designed to make it possible to get the maximum performance out of the latest silicon. It’s bits all the way down.
Some people say C is high level assembly language. They are right. That is what Dennis Ritchie and Brian Kernighan wrote it for. Hardware was changing in bigger directions in their day than now. It was a total PITA to write a routine to, e.g., sort an array of numbers and have to keep rewriting it in the latest set of low level assembly instructions. Say a prayer tonight for the compiler writers who insulate you from having to understand such low level details.
The first stage is turning the characters you type as a C program into assembly code. The compiler that some very clever people wrote for you turns that into an object file that the machine you are working on can use. Don’t confuse that with object oriented programming which came much later. It is just a file of bits that the hardware can ultimately execute.
These object files can be collected into a library and be used by other programs. Static libraries (.lib or .a) copy the bits into the program you write. Shared libraries (.dll or .so) share those bits with all programs executing on your computer.
The second stage is to link together object files (I’m lying a little, there are more stages) and provide a well known entry point to where the operating system can start doing exactly what you tell the computer to do.
To make something happen on your computer you have to execute a file. Sounds harsh, but these are names people called things before the age of political correctness.
The xll library it is a little bit different. Excel is already running. When you open an xll, which is just a dll, it looks for a function called xlAutoOpen and executes that. Set a breakpoint on it and step through all the tricky Excel SDK stuff you don’t have to worry about in order to call C/C++/Fortran.
I’ve updated https://xll8.codplex.com to work with 64-bit Excel if you are following along with the latest. Go to Build/Configuration Manager… and set the platform to x64. Let me know if that is not working for you now, as long as you understand this is not an invitation to debug your code.