February 29, 2012

Using C89 in 2012 isn't crazy

The first group I worked with in industry wrote the compiler in C and made fun of C++ on a regular basis. The second group I worked with in industry wrote the compiler in C++ and made fun of C on occasion. Like most systems programmers I've met, they were a loveable, but snarky bunch!

In any case, I've seen life on both sides of the fence, and there's really simple reasoning that dictates what you choose from C89, GNU C, C99, C++98, or C++11 in the year 2012 AD:

If this sounds simple, you're lucky!

Life gets a little bit more interesting when the match is fuzzy: you could make a strategic gamble and (at least initially) ignore parts of your "maximal" target market to gain some productivity. If you're under the gun, that may be the right way to go.

But then again, keeping your options open is also important. The wider the target market the more people you can give an immediate "yes" to. I have to imagine that phone calls like this can be important:

[A sunny afternoon in a South Bay office park. Just outside, a white Prius merges three lanes without activating a blinker. Suddenly, the phone rings.]

Nice to hear from you, Bigbucks McWindfall! What's that? You say you want my code to run as an exokernel on an in-house embedded platform with an in-house C89 toolchain? No problem! We'll send a guy to your office to compile our product and run tests tomorrow morning.

Suffice it to say that there are legitimate considerations. Consider that GCC isn't everywhere (though I love how prevalent it is these days!) and it certainly doesn't generate the best code on every platform for every workload. Consider that MSVC can only compile C89 as "real" C (as opposed to a C++ subset). Consider that the folks out there who have custom toolchains probably have them because they can afford them.

There are benefits to taking a dependency on a lowest common denominator.