The C++ trap

I came across this wonderful piece of historical retelling by David Beazley, one of my favorite Pythonistas and the author of Python Essential Reference. Here is a man who conquered C++ in just about every way, but ultimately found himself trapped in its byzantine complexity, only to escape by way of Python.

Swig grew a fully compatible C++ preprocessor that fully supported macros. A complete C++ type system was implemented including support for namespaces, templates, and even such things as template partial specialization. Swig evolved into a multi-pass compiler that was doing all sorts of global analysis of the interface. Just to give you an idea, Swig would do things such as automatically detect/wrap C++ smart pointers.It could wrap overloaded C++ methods/function. Also, if you had a C++ class with virtual methods, it would only make one Python wrapper function and then reuse across all wrapped subclasses.

Under the covers of all of this, the implementation basically evolved into a sophisticated macro preprocessor coupled with a pattern matching engine built on top of the C++ type system […] This whole pattern matching approach had a huge power if you knew what you were doing […]

In hindsight however, I think the complexity of Swig has exceeded anyone’s ability to fully understand it (including my own). For example, to even make sense of what’s happening, you have to have a pretty solid grasp of the C/C++ type system (easier said than done). Couple that with all sorts of crazy pattern matching, low-level code fragments, and a ton of macro definitions, your head will literally explode if you try to figure out what’s happening. So far as I know, recent versions of Swig have even combined all of this type-pattern matching with regular expressions. I can’t even fathom it.

Sadly, my involvement was Swig was an unfortunate casualty of my academic career biting the dust. By 2005, I was so burned out of working on it and so sick of what I was doing, I quite literally put all of my computer stuff aside to go play in a band for a few years. After a few years, I came back to programming (obviously), but not to keep working on the same stuff. In particularly, I will die quite happy if I never have to look at another line of C++ code ever again. No, I would much rather fling my toddlers, ride my bike, play piano, or do just about anything than ever do that again.

From this Swig mailing list entry.

3 thoughts on “The C++ trap”

  1. Read “Effective C++” to see that, in general, macros should be avoided, and inline functions are preferred in C++. With possibly very rare exceptions, the only good uses for macros are for code that builds in differently in different configurations (such as debug versus release builds), or code that is platform specific, i.e. windows versus linux, etc.

    In any event, having written C++ almost since the language was created, and being a strong proponent of Python, nonetheless I recognize that neither language is better than the other. Try writing a good video decoder in Python! On the other hand, compare the following two (approximately) equivalent declarations, in each language

    In C++:

    #include
    #include

    std::deque<boost::shared_ptr > my_list_instance;

    In Python:

    my_list_instance = []

    And, the wrapped pointers (wrapped in boost::shared_ptr should only be passed by value. If they are passed by reference, then either leaks or double frees could occur, which is bad. So, C++ is easy to mess up by writing poor code or overly complicated code. (Note, the same can happen in Python, but it is easier to keep code simple).

    Code that takes me an hour in C++ can often be written in 5 minutes in Python, but on the other hand, there’s a lot of signal processing code I would never write in Python, the Python interpreter just i too slow today.

    So, clearly Python is easier to write. Python is more fun to write for that reason.

    My point is that, while “to escape by way of Python” is a true statement, it would be more accurate to state he escaped by limiting the scope of the code he writes to what can be done with Python.

    Note, of course, Python can call C and C++ classes. This is what makes it a really great language – it’s not restricted to itself. (And, of course, what language is Python written in?!)

  2. I’d say he was just burnt out by programming not by C++…

    Currently I’ve got a monster legacy heap of amorphous Java classes sprinkled with Groovy scripts inbetween to debug & correct, and I can understand the “I hate programming” feeling. But I just hate this particular design not Java & Groovy in general.

    @Bill H. Says
    I’d rather write: deque my_list_instance; // _use_ the force 😉

Leave a Reply