Implementing them is a good way to learn it, yeah. Also, you can set breakpoints in some of the functions and run the unit tests, and step through the code to figure out what it's doing. I've always found the debugger to be the best tool for understanding unfamiliar codebases. The code is built very much bottom up, which makes trying to understand it from a top down perspective, which is usually how people like to understand things, difficult. Doesn't help that it's not even really done.
Have you seen
this picture? It's woefully out of date, but but that's roughly how I imagined things fitting together when I first started coding things.
...
Anyway, day-to-day right now I'm working on Azimuth.DenseLinearAlgebra.DenseVector. C# and I have been battling over making the code both readable and as fast as possible. I've been losing that battle, but I'm bringing out the big guns: a C preprocessor. Gonna throw some macros at the problem. Take that C#! I'm working on modifying an existing open source preprocessor so it'll work for the task, and I've basically got it working.
Right now I have to run the preprocessor as a pre-build step. It generates a C# code file, and I'll use
that to build the project with. However, it's not immediately obvious which code is the real code and which is autogenerated, other than a comment at the top. Visual Studio has a way to help with this, though, which is to use the concept of "code behind" getting generated by a custom tool. It's not sexy coding work, but I need someone to code up a DLL that will allow Visual Studio to treat the preprocessor as a Custom Tool. See
Custom Tools Explained. It comes with source, so it should be pretty easy to modify it.
The task is to build the DLL and have it query the input file's first line for the tool to run, and then run that tool. eg: the first line might be //..\..\3rdParty\mcpp\bin\release\mcpp.exe The custom tool takes that, appends the current file's path and a reasonable output file (maybe currentFile.Generated.cs), and then runs that final command. Also, you need to build scripts to register and unregister this custom tool with Visual Studio, which involves registry keys and fun things like that.
I'd normally start working on it sometime on the weekend or early next week, but if you want to tackle it for me it would save me some time and be immediately useful.