Symbian way of implementing exceptions vs Standard C++ way

One of the most interesting and controversial characteristics of Symbian, is the way in which exceptions are implemented. Why am I saying this? Because opinions are split. Is it easier and faster to use leave-mechanism or is just a useless overhead, also in terms of program size, execution speed but also in getting familiar and learning them?

Browsing through Symbian forums and developers’ communities I read (almost) only positive and pro opinions. I also had the chance to go through codeproject programmers community and I have found an article claiming that Symbian OS is mostly designed in a faulty manner and that Symbian C++ is a very obscure and cumbersome clone of the Standard C++ language. I thought of picking several quotes from this article in order to highlight the way exceptions are implemented in Symbian.

There is a paragraph called “Making the key decision based on false facts and statements”, and exceptions’ implementation is given as being the best example. Here it is stated that the “false” premises that led to the implementation of this mechanism was the fact that: “C++ makes the compiled code to grow with 40% in size”. I would not assume that this was the driving reason of implementing the “leaves-mechanism” along with the “two-phase construction”, since Symbian OS developers worked on this well before Bjarne Stroustrup wrote about C++ exceptions.

But before assuming any fake presumption let’s have a look on how the exception mechanism is implemented in standard C++.

In fact … what is an exception?

How I found interesting things about C and C++ languages while learning Symbian C++

It is interesting to see that while reading Symbian C++ code you discover things related to C or C++ language that are not quite the same as you already knew them.
Due to the limitations that a smart-phone has (mostly in terms of power consumption which, from a software perspective, translates into number of CPU cycles required to do something, and in terms of memory size), its corresponding software has to tackle in a very accurate manner some aspects which could be neglected by a PC desktop programmer.

I remember that while browsing a Symbian documentation I read somewhere that:


C++ introduces a memory overhead compared to C (a program compiled in C++ will be bigger than one compiled in C), so if you decide for writing an operating system in C++ you have to be more careful than when writing in C.

One thing which kept my attention when having first contact with Symbian was the fact that you should always use the appropriate data types. This was not very surprising for me taking into account that I have an embedded programming background and I know that I have to be very careful when using unsigned int and when int.
But this is not everything. Symbian even has dedicated typedef’ed data types for each C built-in type (except char and void), and it is strongly recommended to use those instead of C types.

While looking at some examples in Symbian C++ other strange things, like inline constructors, private copy-constructors, private static methods, overloading the new operator with new(ELeave), macros like TRAP and TRAPD, popped into my attention and revealed hidden aspects of C++ language.

Generally if you know C++ it would be quite simple to start writing software for Symbian smartphones. But if this is true, why I read everywhere about the steep Symbian learning curve?

Some examples about how to use descriptors and their associated methods

In this post I will try to outline the some of the functions from TDesC, inherited by rest of the classes and which are currently used when programming with descriptors.

Afterwards I will give some example about how the five types of descriptors are used (HBufC, TBuf, TBufC, TPtr, TPtrC).

Some of the methods defined in TDesC which I saw that are more frequently used are the following:

TDesC::Length

inline TInt Length() const;

as you may see this takes no parameter and returns the length in “characters” that the data pointed by the descriptor has. In case of 16-bit descriptors this returns half the the number of bytes, in case of 8-bit descriptors this returns exactly the number of bytes that data pointed to has. (this is the discussion about the differences between Size() and Length())


_LIT(KText,"Hello World!");
TBufC<16> buf1(KText); // buf1 is the existing descriptor
TPtrC ptr(buf1); // data in buf1 now accessible through ptr
ptr.Length(); // returns the length of the data (i.e. 12)

TDesC::Size

inline TInt Size() const;

We already had a discussion about this, we can skip it.

TDesC::Ptr

IMPORT_C const TUint8 *Ptr() const;

returns a pointer to the data  represented by the descriptor.  Do not worry if you do not understand what  IMPORT_C is meaning, me, I’m also not understanding its significance. All I can say about those macros (IMPORT_C and EXPORT_C) is that they are useful when you want to link to them with another executable application, DLL or EXE. Those macros are making your code accessible outside your program.

TDesC::Compare

IMPORT_C TInt Compare(const TDesC8 &aDes) const;

compares the current descriptor with the one passed as parameter

Descriptors – a nightmare?

As far as  I had the chance to google and to browse through some Symbian developer communities and forums, the answer to this question is likely to be positive for a Symbian junior programmer.

Well … what is in my mind when writing about descriptors? Am I a masochist?
I’m trying not to be and also I’m trying to improve  my Symbian expertise. Why? Does it worth spending the time learning about one of the most complicated operating system ever built? It’s quite difficult to answer but for sure this will not make the subject of this post.

What about descriptors … ?

I think one must regards those descriptors like some predefined data types somehow replacing char type from C, due to its inconsistencies we’ve just discussed.

Descriptors can be classified in six categories: whether they are modifiable or not, whether they are pointers or buffers, whether they are heap or stack based.

How can you differentiate them when writing Symbian C++ code?

Basically you can use just the following types: TPtr (pointers), TBuf (stack based), HBuf (heap based), if one of those type has a trailing C, TPtrC, TBufC or HBuf, this is meaning that they are constant. Below is presented the descriptors’ class hierarchy:

In my opinion a very big leap ahead in understanding descriptors is to have an in-depth knowledge of this scheme above.

Descriptors – a milestone in the Symbian C++ learning curve?

I guess many C enthusiast programmers wanting to switch to Symbian code developing, faced some issues when learning about Symbian descriptors. Even if many useful and helpful resources can be found on the Internet, especially those written by Jo Stichbury (personally I would recommend this one a weblog completely dedicated to descriptors, but there are also other ones which can be found on Symbian developer communities or on Nokia forums), some misunderstandings still persist.

Personally I almost do not know anything about descriptors, I have just some scarce knowledge about Symbian in general, but I am struggling to improve.

Let me tell you how I see the things from a beginner perspective.

First of all two things are important to mention just from the beginning: descriptors (which are somehow equivalent of C arrays) are safer than ordinary C arrays and they are heavily used in transferring data, either on binary format or text.

Before going deeper into descriptors’ understanding I think it is required to clarify why is it so unsafe to use null terminated strings, like those implemented in C.

What is a nul (and it is rather more correct to call it NUL instead of NULL, which has more to do with dynamically allocated pointers – NULL could be something like ((void*)0)) terminated character array?

Let’s turn to Wikipedia and see what is there explained.

NewLC()– a new type of constructor in Symbian C++?

I am in the phase of learning Symbian C++ and Symbian OS, so this is the moment in time when I ask myself many questions about how the things are done.

Everywhere you will read a Symbian programming tutorial you will find a topic about the two phase construction. What exactly is this?

As I wrote in one of my previous posts the memory is a scarce resource when talking about mobile software development. You will have to be careful to code your application keeping in mind that memory needs to be handled very accurately. In general, in embedded programming you do not afford, like when doing PC desktop software development, to have any memory leak or a dangling pointer.

What is a memory leak? It is when you destroy a pointer to a memory location which was not freed correspondingly. The memory location is said to be left “orphaned”, there is no pointer to it so it cannot be handled inside the program.

What is a dangling pointer? Is a pointer that is used to indicate some data which was previously released. A common example is when you return a pointer from a function and that pointer indicates a local variable. A common workaround to avoid such dangling pointer bugs is to lock the pointer to NULL value after it released a resource.

Since in Symbian a lot of applications are relying on C classes (classes derived from CBase class), which are instantiating objects only on the heap, dynamically memory allocation will be intensively used.

One rule of thumb in Symbian is that the constructor is not allowed to leave. OK…