Monday, November 4, 2013

Interlude: code archaeology

Welcome back.

No book content this week; instead, I though I'd share some curiosities I'd rediscovered recently.

As I mentioned, I'll be speaking at the QuantLib workshop in Düsseldorf in a couple of weeks. As part of preparing my talk, I had to do some research on the way the architecture of QuantLib evolved in its early years; so I put on my Indiana Jones hat and dug into the repository for a couple of nights.

Man, it was a blast.

It was like stepping into another era. Well, it was another era, in a way. We're talking about the early 2000s. C++ had become a standard for just a few years, and the various compilers were scrambling to implement it; thus, we had macros and #ifdefs all over the place to check whether we could use a given language feature, or in the worst cases, to select the syntax to use. Not surprisingly, it was especially bad with templates; but it was needed even with simple features.

One example? Since day one, we have tried to write warning-free code, because (as you all know) both disabling warnings and leaving too many warnings around can lead to disregard the one that, once in a while, we should really heed. However, if we wrote something like:
if (some_condition) {
    return 42;
} else {
    return 13;
}
a particular compiler would warn that the function might not return a value (because, being particularly dumb, it wouldn't detect that the execution path would hit one of the two return statements in any case). If we tried to silence the warning by writing:
if (some_condition) {
    return 42;
} else {
    return 13;
}
return 0;
another computer, somewhat smarter that the first, would warn us that the last line would never be executed. The solution? Write
if (some_condition) {
    return 42;
} else {
    return 13;
}
QL_DUMMY_RETURN(0);
and define the macro as return 0 for the first compiler and as empty for the second.

Kids these days have it easy, I say!

On top of this, sometimes we did our part to confuse the code. There was some class which was incredibly bad designed (*cough* Instrument *cough*), but I'm not talking about that. We had things like different code trees for headers and source files, or namespaces nested two or three levels. We had the strange convention that private data members had a "the" prepended instead of the trailing underscore we use now; as in, say, theSettlementDate. We hadn't begun using the pimpl idiom for classes such as Calendar or DayCounter, so we had to wrap them into smart pointers to pass them around (and we weren't using Boost, of course, so we wrote and used our own vastly inferior smart pointer).

In short: you know the particular "flavor" of QuantLib source code? The set of familiar conventions that we use and that help you recognize the parts of the code, like the particular voice of a writer? They were nowhere to be found. As I said, it looked like another era. Or another code base.

If you want to have some fun looking around the old QuantLib, just clone our git repository, run
git log --until 2001-12-31
to get a log of the revisions in 2000 or 2001, and switch to any one of them that strikes your fancy; for instance, run
git checkout eae05182
to get the very first revision we committed (at that time, it was into cvs).

That's all for this week, I guess. Follow me on Twitter if you want to be notified of new posts, or add me to your circles, or subscribe via RSS: the widgets for that are in the sidebar, at the top right of the page. Also, make sure to check my Training page.

Share this post: