Porting the C++ STL to Symbian OS 9.1

Over the last three days I've been working on adapting STLport, an open-source implementation of the C++ Standard Template Library (http://stlport.sourceforge.net), to the Symbian OS. My goal is to port all features of the library, including those parts that were deliberately ignored in previous porting attempts due to limitations of older Symbian systems, such as iostream, fstream and locale.

The standard C library that comes with the new OpenC plugin for S60 is the perfect ground for building STLport, which doesn't require any dependencies other than a decent compiler (both WINSCW and GCCE work perfectly) and a standard-compliant C library. Please note that I'm developing with S60 SDKs only, I don't know whether other kits (such as UIQ) come with a suitable C library or whether OpenC would work on such SDKs. So, for now, the port will be limited to S60 3rd edition.

I'm happy to say that the porting process is close to completion. I managed to build almost everything of STLport on both WINSCW and GCCE platforms and I'm now running unit tests and fixing things as I get errors. I think I've even found a bug in STLport that prevents fstream from working correctly (details here: http://sourceforge.net/tracker/index.php?func=detail&aid=1704843&group_id=146814&atid=766244). The only big part still missing is the support for locales, as it requires a customized implementation. Once I get the library up & running I'll dedicate some time to implement it, in the meanwhile a "dummy" locale implementation is present in order to avoid breaking existing code.

So, what are the motivations behind my decision to port the STL to Symbian? Well, the most obvious one is portability. I've written a lot of C++ applications in the past, especially non-GUI engines and OpenGL-based 3D apps, and all of them are based on the STL. Porting them to a new system/platform can be either a breeze, if the new development environment supports the STL, or a pain, if it doesn't. Moreover, sharing a single code base between different platforms can cut maintenance costs down to about half, which is good.

The second reason is that programming for Symbian is difficult. Antony Pranata once wrote an interesting post on this topic, see http://mobile.antonypranata.com/2005/12/19/why-is-symbian-os-development-very-difficult/. The STL, on the contrary, uses widely-recognized programming paradigms and, even better, it enforces good paradigms by exploiting the C++ language itself. Symbian libraries don't enforce the programming style they require, and I think this is the main reason (beyond the horrible, IMHO, coding style) that keeps novice Symbian developers away from the field. Such programmers are given too much responsibility (i.e. manage the cleanup stack manually) and they need to take care of too many aspects that don't have anything to do with the useful code they want to write. When they try and fail too many times, there is a good chance they will give up and never get back to Symbian again unless they have to.

I'm not going to start a flame about the quality of Symbian code. I'm pretty sure there are many experienced developers out there that don't find it difficult to write Symbian programs, but I also think that it's perhaps even more important to "open the doors" to new developers by making things easier and more standard-compliant. I do recognize the reasons behind Symbian architects' choices: when the OS was designed, the C++ language wasn't even standardized and lacked several features like exception handling, so they had to invent their own mechanisms (leave/trap, cleanup and so on). But come on guys, that was 20 years ago...

Anyway, back on topic. I think I'll be able to publish the final port of STLport for S60 3rd edition in few days. I'm going to release both source code and binaries for WINSCW (the emulator) and GCCE (the real phone). Using STLport will be of course possible from any development environment, including command-line (ABLD) and the Carbide.c++ family of products. Initially I'll compile STLport in the form of a static library, because the resulting binary is very large (8 MB) and making it a DLL would be overkill.

More news soon!