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?

Read more of this post

Advertisements

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

Read more of this post

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.

Read more of this post

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.

Read more of this post