What were the options? They needed a widely-used, performant, reasonably easy to understand programming language.

Web apps? No, Apple tried at first to use HTML + JS, but it didn’t work so they moved to Objective-C. Ruby, Python? Ruby is memory hungry, on the slow side and web-focused. Python is a little faster, which might work if one or two, or even six mobile Python apps were running at the same time. But what about 20 apps?

Objective-C might as well be owned by Apple. C is much too low level and other languages are either niche languages or too domain specific. The only realistic choices for a mobile platform were and still are C++, C# and Java.

Should Google have picked C++? They didn’t have a programming library: by the time Android 1.1 was released, Trolltech had already been bought by Nokia. It’s really hard to create a quality C++ library from scratch, and they probably didn’t care to deal with a third party like Nokia.

What about C#? Google (and pretty much any company) prefers to own the core technologies and decide their fates. If they would have picked C#, Microsoft would have had an important word to say when it came to Android’s future. That left them with Java. It’s popular. It’s also easy to learn, has good enough performance and a massive class library. The only problem were the licensing fees that they had to pay to Sun, but they got around them – or so they thought before Oracle – with Dalvik.

In the end, was Java a good choice? Before the Oracle lawsuit, it seemed so, but Google couldn’t know that Oracle would buy the friendly Sun. They will bitterly fight Oracle, since they have too much of an investment in Java and Dalvik now.

In the mean time, I wonder if anyone inside Google is looking at Java alternatives. There’s already a Qt port for Android, and some official Google love wouldn’t hurt at all.

What’s interesting about these rants is that the ranter isn’t really using C++. They’re C hackers, or they program mostly in Python, or they used C++ at the beginning of the 90s. So I thought it would be interesting to write about my experience with C++.

First, a little background info…

I started learning C++ about 10 years ago, first the C part and then the ++ part. Nothing serious, just toying around with small projects to learn and have fun. I didn’t use it professionally until about four and a half years ago, when I started working on a large scale C++ project. Since then I’ve used it almost daily.

Two and a half years ago I came across Qt almost by accident: the large scale project that I was working on was being ported to Linux and the port was enabled by Qt. Since then, I’ve used Qt almost daily too.

Right now I’m working on a  Qt C++ project that’s about 25KLOC in size and growing. It’s a multi-platform, threaded client-server and it’s a line of bussiness app if you’d believe it. Working on it is fun, and I’m glad that I picked Qt and C++.

Okay, enough with the history, what about C++ and its warts?

Issues that bother me in practice

• Compile times and the include dependency specification: this is a problem that every C++ programmer will have sooner or later. It can be delayed and mitigated with a good physical design, precompiled headers and distributed compilers/linkers, but it can’t be solved without throwing away compatibility to existing code completely.
• The small standard library: not a big issue in itself, since you can find other libraries for anything you might want to do, but it’s unpleasant to install all those libraries and make sure that they work together nicely. Using more libraries instead of a large standard library also means that you have to wait on each library vendor to port the library to different OSes/compilers, upgrade it and so on.
• lack of reflection: I like Qt’s moc and I miss it in standard C++. I also wish it had more features.
• lack of type inference: even with typedefs I’m typing more than I have to. C++0x will thankfully fix this.
• localization & internationalization support in the standard library: the implementation is complicated and difficult to use. After browsing through C++ IOstreams and locales I’ve decided to just use Qt and not worry about it.
• template error messages: they’re long and hard to understand. I usually parse a template error message in about 10-20 seconds depending on the difficulty. The worst offenders are metaprogramming-heavy libraries such as Boost Spirit. In that case, I try to analyze the code first and see what might be wrong. STLFilt can help.
• functional programming support: this will get better in C++0x, but I can’t use C++0x now, at least not on all platforms and with the other libraries I’m using. Functors and free functions are cumbersome to use with algorithms.
• tools and parsing: C++ has access to solid, mature tools, but those tools are much harder to develop than for other languages and generally don’t have as many features.

Issues that don’t bother me at all, but are regularly brought up in rants

• memory management: never a problem for me. The last time I’ve had a memory leak was about two years ago and it got caught at code review. C++ has good support for memory management and good tools that can be used for runtime debugging. It might as well have GC, I wouldn’t be able to tell the  difference.
• memory corruption: memory corruption can be both exciting and scary. Exciting because you have to go down to the memory address level and do some sleuthing, scary because it can take days or weeks to find some bugs. I usually don’t sweat these bugs, they were very rare in the code I’ve worked on, and when they occurred they were easily found. e.g: the last one I’ve solved in maybe 30 seconds, the tools have gotten very good. The worst I’ve encountered was a problem with an embedded STL in a large project that took a week to figure out and only because of my lack of experience at that time. Some people love debugging.
• multi-threading: it is hard in most languages. The trick is using higher-level libraries such as QtConcurrent, Intel’s TBB or OpenMP. Sure, if you’re doing PThreads it’s going to be painful.
• string formatting and string support: I generally don’t use iostreams or std::string, but when I did I found them acceptable. Unicode support was the biggest issue, but “there’s a applib for that”. Now I use Qt’s strings and streams; they’re as easy to use as Python as far as I’m concerned. Don’t want Qt? Use boost::format or any other of the nice formatting libraries.
• templates in general: I use them when needed to break dependencies, write generic code, etc. I try to keep template code manageable, without going into the metaprogramming stuff; they are one of my favourite C++ features.
• exception rules: I don’t see any problem with exceptions in C++ as long as you’re using RAII. Other languages (e.g.: Python) use them extensively for error handling.
• STL & Boost: I’ve used both for a lot of time and I find them very useful. Contrary to popular belief, most templates don’t use metaprogramming techniques. You don’t have to install Boost, it’s mostly headers. A large part of Boost became TR1 so it should even ship with your compiler now.
• const: This one came from Zed, I don’t think I’ve seen that many people complain about const. Personally, I constify everything that I can, even const type* const.
• everybody learns a different 10% of C++: strange, because I use all of it and always have. It’s not that hard either, I’m not a genius… Sane projects have coding guidelines and architectural documents. If your teammate can waltz right in with a template metaprogram or is generally macro-happy and it doesn’t raise eyebrows at code review, you have bigger problems than using C++. I’ve had to fix two C++ projects so far; my only job was to do what it takes to make the programs work and ship them to the customer. Most problems were memory leaks, superfluous use of casts, functions that didn’t compile on all platforms and so on. Fixable. What I couldn’t fix – and had to patch up as best as possible – were issues with the program logic and architecture. Those were not caused by C++.

Ok, but what about…

You probably have your favourite C++ misfeatures.  Odds are that they don’t matter than much in practice, or workarounds are available. Maybe I just got used to them and consider them a C++ tax.

Here’s a workaround:

• Add the flags -Wno-attributes -Wno-parentheses to the Symbian compiler flags. This will fix the dllimport warnings and the “recommend parentheses around…” warnings. e.g: symbian {QMAKE_CXXFLAGS += -Wno-attributes -Wno-parentheses}
• Edit the file e32cmn.inl and replace the C-casts at the warning lines with reinterpret_cast. e.g: (const TSecureId&)iId will become reinterpret_cast<const TSecureId&>(iId). The conversion seems to be correct, even though the implementation is hack-ish.
  

In one project – after doing the two changes outlined above – the warning count was cut from ~4000 to about 41. There weren’t 4000 real warnings, more like ~100 but Qt Creator counts each warning line as a warning (this might be a bug).

The remaining warnings were:

• d32locd.h:189: warning: invalid access to non-static data member ‘TLocalDriveCaps::iSize’ of NULL object
• d32locd.h:190: warning: invalid access to non-static data member ‘TLocalDriveCapsV3::iFormatInfo’ of NULL object
• openfont.h:2549: warning: invalid access to non-static data member ‘COpenFontRasterizer::iDtor_ID_Key’ of NULL object
• openfont.h:2571: warning: invalid access to non-static data member ‘CShaperFactory::iDtor_ID_Key’ of NULL object
• biditext.h:12: warning: declaration ‘enum CGraphicsContext::TTextAlign’ does not declare anything

1-4 seem to be related to the use of the _FOFF macro., but I didn’t do any detailed analysis.

    QMAKE_CXXFLAGS += -Wno-attributes -Wno-parentheses

The port didn’t involve many changes:

• I have fixed a bunch of warnings caused  by the Symbian GCC not liking if(); These could have probably been disabled with compiler options, but I just replaced the ; with an empty block.
• I have added Symbian-specific debug output. The logging output will be captured by Qt Creator and shown in the “Application output” view.

Via Lucian from Symbian dev foundation I found out that the recommended folder to place your logs on Symbian  is c:/Logs/<dir>. I use the program name as <dir>, but it’s not mandatory.