What's next?

What's coming after the release of STLport for Symbian OS? Well, at least a second release will follow shortly, possibly including a full implementation of STL locales and a fix for the missing typeinfo header in the platform SDKs. I'm also considering the possibility of building STLport as a DLL, or as a set of DLLs if a single binary is too large. This will help reduce the size of application executables, saving precious space on the device's memory.

The STL is just my first step towards a better development platform on Symbian OS. The second step will be longer and probably more difficult: porting Boost libraries. If you don't know what the Boost project is, please have a look here: http://www.boost.org. I think every serious C++ programmer should know Boost, regardless of whether he/she decides to use it or not. It's a matter of fact, some developers love Boost and others just can't live with it. I personally love it, in my opinion it is the perfect complement to the STL and to the C++ language itself. The reason why some programmers don't like it is that it is radically different from other libraries, which are usually based on (and often abuse) "ordinary" OOP paradigms and idioms. In contrast, Boost libraries try to enforce those features that are unique to the C++ language, such as compile-time polymorphism and template metaprogramming, resulting in higher-performance elegant code that can be extremely reusable if designed well. The downside is that using Boost is usually more difficult than using other libraries, and that's especially true for developers who don't write C++ programs "the C++ way". If you don't know what I mean, I suggest you to read this excellent book by Herb Sutter and Andrei Alexandrescu: C++ Coding Standards, a must for every C++ programmer.

Of course, neither the STL nor Boost libraries can replace the Symbian API and its nonstandard set of paradigms, rules and guidelines, but they can serve as a base for building an interface layer to abstract away the intricacies of Symbian programming and finally make writing software for this platform easier, safer and faster.

These are my long-term plans. Maybe they're too ambitious, given my lack of spare time...

STLport for Symbian OS released!

STLport for Symbian OS has been updated! A pre-release of version 5.1.5 (source code only) is available here.

I'm happy to announce the first full-featured release of STLport for Symbian OS 9.x!

STLport is a high-quality implementation of the C++ Standard Template Library (STL), a library that is part of the ISO/IEC C++ Standard and that is not included natively in the Symbian OS platform. By supporting the STL, Symbian applications can benefit from a wide range of existing C++ code that can now be ported easily.

This version of STLport should work on all Symbian OS 9.x devices, both S60 and UIQ variants. The library has been succesfully compiled with (and binaries are provided for) following platform SDKs:

• S60 3rd Edition 1.1 (Maintenance Release)
• S60 3rd Edition Feature Pack 1
• UIQ 3.0

The only dependency is a conforming Standard C library, that is provided by either the P.I.P.S. library (available for both S60 and UIQ devices) or Nokia's Open C plugin (S60 only).

All features of STLport have been ported, although locales other than the default "C" locale are not yet implemented. This will be done in next releases. All unit tests have passed on both the emulator and a wide range of devices, while only one test in the exception handling testsuite is still failing. More details are available in documentation files that come with the downloadable package.

So, now the interesting part. If you are using one of the aforementioned SDKs and you don't need to change any of the STLport configuration options, then you can download the prebuilt package that includes header files and binaries for a specific SDK:

Download prebuilt package for S60 3rd Edition 1.1 Maintenance Release SDK

Download prebuilt package for S60 3rd Edition Feature Pack 1 SDK

Download prebuilt package for UIQ 3.0 SDK

Download the README file that contains installation instructions

Please note that binaries for S60 were compiled against the OpenC library, while those for UIQ were compiled against the P.I.P.S. library. If you want to compile the library for another SDK or if you want to change the build configuration, you need the full source code so that you can recompile STLport from scratch:

Download full source code

The source code package also contains the necessary files for building an installable SIS package containing the STLport test suite.

If you have any questions or suggestions, please let me know. I can be contacted on the Forum Nokia's discussion forum, my nickname is "polo78".

Enjoy!

STLport coming tomorrow for both S60 and UIQ!

The first release of STLport for Symbian OS is ready, and the big news is... It works on UIQ 3.0 too! The only practical difference is the standard C library, which is Symbian PIPS on UIQ and Nokia's OpenC plugin on S60. These two libraries are actually very similar and have some parts in common, but whereas OpenC includes a "stdio server" for displaying and/or redirecting standard streams, PIPS apparently doesn't have such feature. This means that C-style console applications based on PIPS can't display messages through functions like printf(). Initially, this limitation was an issue because I couldn't run the STLport unit test program to test the library on the UIQ emulator or on the device (I've bought an used M600i phone from eBay), but I solved it by writing a simple shell application that launches the STLport test programs and captures their output.

So, everything is in place. There is a good chance that I'll be able to make the release available for download by tomorrow night.

STLport and the problem of destructors not being called in Symbian OS

While I was away I did some additional testing on my STLport variant for Symbian OS and I noticed an annoying fact: everytime a GUI application terminates, even gracefully, an ALLOC panic is raised on the emulator indicating a possible memory leak (which is a rather common bug in programs). It turned out that STLport uses a sort of optimized allocator to manage memory allocation and deallocation for STL containers and other classes. Such allocator is a global object that pre-allocates memory on its own strategy, but it doesn't free all allocated blocks when the program ends (I think that's because the operating system is supposed to do the work). This is not a problem under normal conditions, but Symbian GUI apps usually try to detect memory leaks by marking the heap and tracking memory usage throughout the program execution, thus raising an ALLOC panic when the STL-based applications ends. Although this is benign and doesn't happen on the real device (memory leaks are only detected in debug builds), it makes the useful memory leak check completely useless, which is bad.

After a bit of investigation I discovered a configuration option in STLport that forces the optimized allocator to release all allocated memory on program termination. I tried the same test with that option turned on, but nothing changed. Apparently, the reason is much more serious than I initially thought: it seems that class destructor of global objects in Symbian applications is never called, even though it is supposed to be called (as per the C++ ISO/IEC Standard) when the program exits cleanly. In the case of STLport, this means that memory still owned by the optimized allocator is not released on exit. This is a serious malfunction of the Symbian application model in my opinion.

I asked other developers at Forum Nokia an explanation for this fact, with no luck. Some users confirmed that destructors are not being called, but neither a motivation nor a workaround emerged from the discussion. For now, I'm simply switching off the optimized allocator in STLport, falling back to the "direct" malloc/free allocator, which may be a bit less efficient but at least it doesn't leave allocated memory around.

Back to work now, more news soon.