C++ and Python project config

Before I started writing commercial C++ code a couple of years ago, I had just begun to reach a wonderful state of Zen with python. I had developed good personal balance of prototyping, code organization, and debugging techniques that I still haven’t seen the likes of with my C++ project. If anything, the biggest advantage that my python projects had over my C++ projects is impeccable project config. With no compilation and the guarantee that the code would run the same accross platforms, the fight was over before I even started coding.

These days I spend 50% of my time either writing code or managing a Visual Studio or XCode build system to fit the needs of the compiled language’s environment. Third party vendors don’t accurately support audio plugin standards, their objects are compiled with a different runtime than ours, and their headers conflict with ours and cause others to bail completely (windows.h, anybody?). Strong typing causes twice the code bloat and twice the up-front design effort that the interpreted language took. The code is unreadable; the macros clutter up the logic, the indentation is all over the place, and there’s just plain too much of it. Worst of all, our repository is totally fragile, which seriously stresses out my boss.

When you code in C you get speed and easy debugging, which is important for projects like ours, which consists of a separated gui and dsp engine that is instantiated as an audio plugin with popular music sequencing hosts like Ableton Live, Pro Tools, Logic, and more. These days we are still writing for scalability and performance, so the engine has to be written in C. We debug our gui code and step into the engine on a regular basis, so writing the gui code (> 50%) in python and trying to debug the engine would be very difficult.

Theoretically the gui code would have been so easy to write in python that we wouldn’t have needed to debug it, and could have just debugged the engine using C++ breakpoints in XCode and Visual Studio as we do now, but I wouldn’t know without trying it. One thing is for sure, coding with a clear conscience would have required a solid set of tests to work out all the bugs we’ve run into using Qt as a graphical toolkit from within a native application. With the tremendous overhead of writing unit tests for this stuff, we would never have met our initial project deadline, and I would never have had the opportunity to look back and grumble about our choice of language.

Maybe it’s possible to get around these problems with better plugin standards? Or maybe having a really really good python-based plugin dev platform to work with would help.

Anyway, back to the topic. I originally wanted to write about the stylistic differences that separate python and C/C++ projects. Here’s what I’ve found:

Python induces highly modularized code that is still readable, while in C it’s much easier to read code that is written in larger blocks. Remember that big, long function that you wrote in your first college class?

When I code in C++ I end up spending most of the time coming up with solutions that work for the syntax of the language, as opposed to using that time and energy to focus on the functionality of that code. I eventually stopped using a debugger with python because I was able to produce pieces of code that worked well from the start, or could be quickly fixed using print statements and some sort of unit test using an “if __name__ == ‘__main__’:” block. With C++ I ended up writing verbose code that is easily debuggable, for example always using temporary values of built-in types to expose the state of the stack.
The biggest difference, though, is that I got very comfortable with being a style nazi when reading and writing python code. The difference is that it just doesn’t matter what the code looks like in C++ as long as it runs. We have three primary developers in our project that all use whitespace differently, name our variables and methods with different conventions, and it’s pointless and also unnecessary to try to change them. You just jump into the C code and fix the problem, leave the crazy indentation from your tabified copy and paste, then just compile it and make it work, and work fast.
I do miss the unified indentation, simple syntax, and no crashes, compiler flags, or linkage problems have cost us a lot of man hours, not to mention stress for my project manager. Most of all, I miss just sitting down and solving problems 100% of the time.
By | 2008-07-23T22:55:00+00:00 July 23rd, 2008|Uncategorized|0 Comments

Leave A Comment

10 + = 14