Top/Bottom C++
As someone who has spent an awful lot of time wrangling really large C++ codebases, I really enjoyed John D. Cook’s recent blog post Why do C++ folks make things so complicated?.
I think that he’s pretty much on target about why big C++ projects end up so darn ugly. Well structured architectures usually have layers of performance critical components and layers of more dynamic configuration code. The pattern Alternate Hard and Soft Layers describes it pretty well. C++ is a great tool for the low-level components (which Cook calls Bottom C++). It’s also possible to use it for the configuration layer (which Cook calls Top C++). There are even some advantages in doing that. Using a scripting language for the configuration layer usually involves some glue code, impedance mismatches, and debugging hassles around the language boundaries. Doing both layers in C++ avoids all of that.
The problem is that when you’re creating this type of architecture, you really want to use a different style of programming in each layer. That is possible in a language like C++. It does support a wide variety of idioms and programming styles. But when you do that, programmers forget which layer a piece of code belongs to, and write it all in the same style. That’s a lot easier to remember to do if you have to change languages when you change layers. As a practical matter, that seems to outweigh the disadvantages of introducing a language boundary for any codebase of significant size.
Of course, if there’s Top and Bottom C++, that must mean that there should be Charm C++ and Strange C++ too. Come to think of it, I guess that I’ve seen plenty of strange C++. Not so sure about the other though.
