A developer's blog.

Reading suggestion

2011-04-05T08:52:00.000+01:00

Sometimes its difficult for me (as a developer who thinks object oriented) to read and understand C code.

Object oriented programming and structural or functional programming are two different worlds.

After reading this article my view has changed in most ways.

http://www.pragprog.com/magazines/2011-03/punk-rock-languages

What the compiler could mark as an error

2010-11-30T05:45:00.000Z

Never call virtual functions from within constructors of the same class. This can lead to an access violation. The call will be dispatched to the the overridden function. Now imagine there's a derived class which holds this override. In case the base class constructor calls the polymorphic function the dispatch is done before the derived class instance is constructed entirely - slicing. Got it? This function will access fields which are'nt there at all.

Prozess/Thread

2010-04-28T10:43:00.000+01:00

Dieser Post ist nur in Deutsch verfügbar. Ist mehr einen Notiz für mich selbst als für andere.

Prozesse und Threads sind die Basis für Multitasking.
Prozess = Ausführungseinheit mit eigenem Speicher (Heap u. Stack), Jeder Prozess hat immer mindestens einen Thread (Main-Thread).

Thread = Jeder Thread hat seinen eigenen Stack. Threads des selben Proc teilen sich den Heap.

Multitasking funktioniert mit Kontextswitch. Wird von einem Thread zu einem anderen Thread im selben Prozess gewechselt, werden die Register, Stack, etc. des zu verdrängenden Threads "stored" und die Register, Stack, etc. des verdrängenden Threads "restored".

Das gleiche wird auch gemacht, wenn von Thread A zu Thread B in unterschiedlichen Prozessen gescheduled wird. Jedoch ist hier zustätzlich noch die Memory Management Unit beteiligt, die den jeweiligen Speicherbereich des Prozesses stored/restored, also erheblich mehr Overhead.

More introducing than going into deep - some things you should have heard about when programming OO

2010-04-28T10:39:00.005+01:00

call by value vs. call by reference
lazy fetching
early fail
trivial construction vs. non-trivial construction
value semantic
shallow copy vs. deep copy

Some OOP termini and their translation into C++:
1) object owns another object (has a relationship - aka wrapper)
2) object uses another object (uses a relationship)
2a) object reads another object (solved beeing const correct)
2b) object manipulates another object (non const qualified)
3) object "can" use or have another object (weak aggregation - can be solved using pointers)
4) object is a special form of another object (public inheritance)
5) object is a general form of another object (public inheritance)

declaration (usually done in header files)
definition (usually done in implementaiton files - *.cpp)
initialization (prefer initialization lists - member pointers have to be zero initialized)

static
non-static
this (why did Bjarne Stroustrup invented this to be a pointer - could'nt it be reference instead?)
const
volatile

buildin types vs. custom types

This list is more a collection of notes for myself but I had no clue where to put it elsewhere.

Comments disabled

2010-03-01T12:43:00.000Z

During the past weeks and months I have recognized comments written in some far east language. That's the reason for disabling this feature. It is unclear if it will be enabled again.

If someone wants to give a comment for a particular post he or she can send me an email and I will try to consider the comment in the belonging post.

Swapping

2010-02-22T13:28:00.002Z

TPtr8::Swap() can be seen as Symbian aquivalent to std::swap(). If the advantages of "swapping" are not clear I will give some example(s) later.

Which STL container fits best?

2010-01-13T09:21:00.003Z

Yesterday I stumbled upon a very nice diagram. Its a decision graph for getting the best fitting STL container for certain needs.

I really like two comments on this page.

Simple answer: use vector<> for everything unless you have a real reason to do otherwise.
One lesson i've learned is, try to wrap it in a class, since changing the container type one fine day can yield in to big surprises.

Releasing Resources Is Destruction

2009-06-16T11:21:00.005+01:00

Nearly everybody knows the popular design pattern RAII (Resource Aquisition Is Initialization).
In short: when getting a resource it has to be bound to a certain object (in C++ known as Smartpointers e.g. std::auto_ptr<>).

The clue is that releasing the resource is handled automatically through destruction of the management object. So this popular design pattern could also be called Releasing Resources Is Destruction (RRID).

When writing standard C++ applications it is ensured that stack located objects are destroyed via stack unwind in case the function returns normally (not by an exception). In Symbian OS C++ this is the case too. But what happens in case of an irregular return from a function (in case of an exception)?

In Standard C++ the compiler generates an unwind list for every function that creates objects on the stack. This unwind list is processed in case of an exception. So the created objects are destroyed. In Symbian OS before v9.1 such an unwind list simply did not exist. So POD types were simply deallocated (no destructor was called). But NonPOD types have to be pushed onto Symbian OS' so called CleanupStack. This stack is processed in case of an exception (and only in case of an exception). I never knew why the compiler implementers didn't implement CleanupStack unwind in case of regular returning from a function. But that's not the topic here.

The change since Symbian OS v9.1 is that the compiler generates an unwind list for functions which create objects on the stack and during stack unwind in case of an exception these objects are destroyed correctly (with a call to the destructor). This is why the auto_ptr<> class template is working nicely for Symbian OS v9.1 and later without the TCleanupItem object (see chapter 1.4 in the mentioned PDF).

Usefull CIdle in RunL() of a CActive derived class.

2009-04-03T09:11:00.001+01:00

The main purpose for which I am using instances of CIdle is in the RunL() method of a CActive derived class.

Everywhere you read that a RunL() method has to complete as fast as possible for not blocking incoming events for other CActive derived instances. But how can this be achieved?

The solution is to "wind up" a dispatcher in the RunL() method.
For this the CActive derived class has to aggregate a member of type CIdle*.
In the body of RunL() the following code is implemented.

void CMyCActiveDerived::RunL()
{
/* ... some handle code ... */

if (!iDispatcher) iDispatcher = CIdle::NewL(CActive::EPriorityNormal);
else iDispatcher->Cancel();
iDispatcher->Start(TCallBack(EventHandlerL, this));

/* ... some optional code ... */
}

The CActive derived class has to provide a static EventHandlerL method. Optional you can use any static member function from any other class. The second argument of the temporary created TCallBack instance is a pointer of any type (a void* ;-))

The advantage: The current stack frame is destroyed and the event handler code is called in a delayed way. That's decoupling.

Any comments appreciated.

Sad about bankruptcy of UIQ Technology

2009-01-20T20:10:00.003Z

I am sad that UIQ could not make it through this crysis because I always liked developing for this platform.

Simons Blog

Accredited Symbian Developer

2008-12-02T11:43:00.004Z

Today I did the exam. After 120 minutes and 48 questions I am an official Accredited Symbian Developer now!

Forward declaration aka prototyping

2008-11-06T14:46:00.003Z

Something you have to keep in mind:

Forward declarations in header files are only possible if the header file only contains reference or pointer types of the forward declared type.

Another thing you can have a typedef to a container of custom value types (e.g. typedef RPointerArray RMyArray;) somewhere in the headerfile custom.h. Your compiler will give you errors if you only prototyp the RMyArray in another headerfile special.h even if the headerfile only uses references or pointer types of RMyArray (RMyArray& or RMyArray*)

The solution is that you have to include custom.h at the beginning of special.h.

But this was a hard way to find out. *puh*

Symbian OS Internals

2008-10-30T08:43:00.001Z

The Symbian OS kernel explained in this free online book.

Don't mix "const TDesC&" and "TPtrC"

2008-10-13T10:00:00.008+01:00

As TPtrC can be seen as a constant quasi reference to a descriptor. Don't mix it with the real reference type for descriptors TDesC&.

Attention wrong sample code:
const TDesC& GetDescriptor() const
{
_LIT(KDescriptor, "Hello");
TPtrC des(KDescriptor);
return des;
}

This is a programming error: "Returning a reference to a locale variable." Which results in a runtime error (panic).

Rule: Don't you ever return a TPtrC when your function returns a const TDesC&!

The problem here is, that often you don't see that des is a TPtrC! E.g. when GetDescriptor() calls another function which returns a TPtrC! So you have to be patient.

Solution: Your function has to return a copy of the TPtrC. And the prototype of the function looks like this:
TPtrC GetDescriptor() const;

UIQ3 Book online

2008-10-09T09:32:00.002+01:00

Here is the complete online book for developing for the UIQ3 platform.

On device debugging S60 applications

2008-06-19T11:41:00.007+01:00

Sorry for posting this topic so long after my anouncement here.

But finally I could evaluate the on device debugging (ODD) functionality of Carbide.C++ 1.3.1. with 2 S60 SDKs: the 3rd MR SDK and the S60 3rd FP1 SDK.

First the ODD feature works with some minor disadvantages. Second you need at least a Carbide Developer license (which costs about 300€ in the Nokia e-Store). I could test it with an evaluation license.

Didn't work:
- dereferencing of the this pointer in the scope of a non static member function could not be done (members could not be examined)
- automatic descriptor variables could not be evaluated in the scope of a function (content could not be examined)

Worked great:
- debugging of an import library (aka static link library)
-

Here comes a short step by step guide for debugging a simple application on device:

Install App TRK on your Symbian S60 phone (you can find it here).
Ensure the phone is connected to the computer and is connected via Nokia-PC-Suite too.
Ensure your application is buildable for WINS emulator with Carbide.C++ IDE.
Switch the Build condiguration to GCCE (debug) you can use the S60 3rd MR or FP1 according to the device you are using (e.g. an E60 uses the MR SDK, an E90 uses the FP1 SDK). You can reach the build configuration dialog by right clicking on the project.
Right click on the project, select "Open debug dialog", ensure there is nothing preconfigured under "Symbian OS Application TRK". If there is something preconfigured you can delete this subitem by clicking the red cross above that dialog. This step has only be done the first time. Every other step OOD session you can use the following configuration.
Close the debug dialog
Right click on the project, select Properties.
Select Carbide.C++ subitem in the properties dialog. And after this the Carbide Build configuration subitem.
Select the desired configuration. I use "Phone Debug (GCCE) [S60_3rd_FP1] because I use an E90 for ODD.
In the below "Sis builder tab" add a new entry by clicking on the "Add" button
In the following dialog browse to the location of your projects package file (pkg extension)
Insert an output filename (insert: .sis)
Leave content search location empty
Because I have a developer certificate from Symbian, I use "sign sis file with a certificate/key pair"
The signed sis file name will be: ".sisx" (recognize the trailing x)
Insert the password for the "signsis" procedure
Leave additional options empty
Browse to the location of your certificate file (.cer extension)
Browse to the location of your key file (.key extension)
You can now build your project for the target. Rightclick on project and select "build project"
Observe the console output: after a successfull build a successfull makesis step is performed and after this a successfull signsis step
You are now ready for debugging. Rightclick on project, select "debug as" > "Debug symbian application".
A dialog shows up "New launch configuration", select "Application TRK Launch Configuration" > "Next"
Ensure the correct exe is preselected in the "Process to launch" selection box. "Next"
Select the correct COM port for your device connection. Usually after the COM port the name of the device is shown. In my case I select "COM 14 - Nokia E90 Communicator USB" > "Next"
Ensure the correct sis file is preselected. You can do this by comparing the filepath with the files in this directory. During step 21 the sisx file was placed in the folder \projectpath\sis\project.sisx. Simply check if both paths (the preselected and the real path in your filesystem) are the same. "Next"
"Finish", the debug session is started and the application shows up on your phone.
If you have put a breakpoints within your sourcecode the processing is stopped here and you can debug ;-)

The steps 15 - 19 should be known from signing a sis file on command line. You can do it in another way when not signing a file or signing a file with a selfsign certificate.

I hope this post is helpfull. Any feedback is appreciated.

Deinstalling/Installing S60 3rd SDK

2008-06-02T11:36:00.003+01:00

When deinstalling the SDK for Nokias S60 3rd platform the registry key HKLM/Software/Nokia/com.nokia.s60/Instances contains the count of the installed SDKs. This registry key is not set back to 0. So when installing the SDK again the instance key is increased by 1. But the installation path suggested by the installer now contains a _2.

For avoiding this you can manually reset the instance key to 0 after deinstallation and do a fine new installation rightafter.

Object oriented relations and its implementation in C++

2008-04-24T10:49:00.006+01:00

Object oriented relations and its implementation in C++:

Has a - aka composition

Is implemented with member variables. If the member is heap allocated then the implementation happens with pointers. In this case the pointee object has to be destroyed when the aggregator is destroyed.

Uses a - aka aggregation

Is implemented with member variables of type "reference (&)". When the aggregator is destroyed the aggregates are not destroyed.

Can use a - aka weak aggregation

Is implemented with member variables of type "pointer (*)" but the pointer is initialized "empty" (with NULL) and set later to point to a certain object. When the aggregator is destroyed the aggregates are not destroyed.

Is a - aka inheritance

Public inheritance (all public members of the base class are accessible by a user of the derived class).

Private inheritance (all public members of the base class are hidden from the user of the derived class). This kind of inheritance is used for providing a "new" interface. It is also known as "class Derived is implemented in terms of class Base".

C++: static types vs. dynamic types

2008-04-04T08:47:00.002+01:00

When using polymorphic types it is good to know the difference between the terms dynamic type and static type.
An object can have booth kind of types. The static type is an objects "real" type whereas the dynamic type is a "base class" type.

Base* pObj = new Derived(); // *pObj's static type is "Derived" whereas the dynamic type is "Base"

Easy spoken: the static type is the real type of the object (right hand side type) and the dynamic type is the polymorphic type (left hand side type).

Polymorphy can only be done with types of pointers or references. Casting between static and dynamic type is usually done with C++ dynamic_cast<> opererator. This cast performs a runtime check for ensuring the Base class pointer can be casted into the specified Derived class pointer.

Some things to keep in mind when using a CActive derived class as a proxy

2008-03-27T22:28:00.004Z

For some reasons I needed a CActive derived class as a proxy. Being more clear a CActive derived class (A) instance didn't issue the asynchronous request to the Asynchronous Service Provider (ASP) directly instead it issues an asynchronous request to another CActive derived class (B) instance which issues the asynchronous request to the ASP. For this B has to provide an asynchronous request function which takes a reference to A::iStatus as parameter.
Within that function B issues the asynchronous request to the ASP passing in its own iStatus instance. After that (and I mean after - not before) the B instance has to set A::iStatus to KRequestPending and store a pointer to A::iStatus in an own member variable (e.g. B::iCallerStatus).

The reason why I mentioned the after is in case of an exception thrown by calling ASP::AsyncRequestL() the A::iStatus whould be pending and the Active Scheduler finds an iStatus pending without having an appropriate object "SetActive()". This results in a classic stray signal panic.

When the asynchronous request is completed by the ASP - B::RunL() is called and B::iStatus can be evaluated. In this case the outstanding request of the class A instance is completed via a call to User::RequestComplete(iCallerStatus, iStatus.Int()); It is good practise to check iCallerStatus against NULL before completing.
Rightafter A::RunL() is called and A::iStatus can now be evaluated.

The details with issuing asynchronous requests are explained in several SDK documentation.

Assertion statements

2008-02-28T15:38:00.003Z

Symbian OS C++ has some nice assertion macros (__ASSERT_ALWAYS() and __ASSERT_DEBUG()). These can be used to make assertions in your code. Being more clear: To ensure that an expression is true (e.g. a pointer is valid). This expression is placed in the first argument of the assertion. The second argument specifies what is performed when the assertion evaluates to false. Here you can place a panic calling function or throw an exception or do whatever you want. Good style is not to place code with sideeffects into an assertion. That means neither the left value nor a right value within the expression is changed. E.g. an evaluation is an expression without sideeffects wereas an assignment is an expression with a sideeffect to the left value.

The assertion macros can be easily coded for usage on other platforms which use C++.

First impressions on ODD

2008-01-31T10:04:00.000Z

After testing the RC1 of the Carbide.C++ IDE for 3 days I could gain first impressions on On-Device-Debugging (ODD):

before starting the debug session the application has to be signed and installed onto the device - this is easily handled by the IDE (debug options build configuration and sis builder)
after that I could debug a console application very easily
I have linked the application against a static link library but when trying to "step into" a function the debugger "stepped over" it :(
I also tried to debug a GUI application for Nokia's S60 platform but in this case no breakpoints were reached and the debug session behaved like I was running the application in "non-debug-mode"
so debugging via cable worked fine for me
next things I will test are:

debugging via Bluetooth (BT)
debugging a UIQ3 application on device

Release Candidate 1 for Carbide.C++ is available for download

2008-01-29T08:56:00.000Z

As you can read here the Carbide.C++ IDE Version 1.3 development reaches its final state.
I will check out On-Device-Debugging as soon as I can and post my comments here.

static and const member functions

2007-12-13T13:04:00.001Z

A const member function ensures at compiletime that this member function does not change an instance of its class.
A static member function does not has the dynamic aspects of an instance of the class because it has no this pointer. So it has the same behaviour for all objects (instances).

When designing a new class you have to provide a set of member functions this class has. It is so called good style to set all member functions which do not "need" the this pointer to be static functions. All non-static member functions have to be const or non-const. So when a function does not change the object make it a const function! Keep in mind that const functions are only allowed to call other const functions of that class, otherwise your compiler will grumble!

Not using const and static is bad style!

Carbide.C++ 1.3 Beta is ready for testing

2007-11-19T09:35:00.000Z

As Mike Trujillo announces on Carbide.C++ google group the version 1.3 of the Carbide beta is downloadable for testing.

Tutorial on NewLC

2007-11-12T10:28:00.000Z

I have published my first tutorial on NewLC. It is about a templated class for automatic cleanup of Symbian OS' typical R classes. You can find the tutorial here.

Never instanciate R classes on the heap directly

2007-11-01T09:01:00.000Z

A Symbian R class can be seen as a "handle to a resource". Some examples: RBuf is a resource handle to a buffer. RSocket is a handle to a "socket" resource provided by the RSockServ which is also a handle to a resouce aka the socket server. It does not make sense to instanciate such a class on the heap because instanciation on the stack works well. There is no necessity to do it.

Difference between overloading and overriding

2007-08-15T11:08:00.001+01:00

Overloading and overriding explains how a member function is bound to its object. Both kind of functions are dynamically bound to its object. Overloaded functions are horizontally bound while overridden functions are vertically bound. Horizontally and vertically is related to the inheritance hierarchy.

The ten commandments for C programmers

2007-07-05T08:40:00.000+01:00

Found here. Keep this in mind when developing for C++.

Nice introduction into Symbian OS C++

2007-06-12T10:28:00.000+01:00

I found a nice introductory presentation into programming C++ under Symbian OS. It can be found here.

Client Server Framework messages

2007-05-31T11:46:00.000+01:00

When using Symbian OS's Client-Server-Framework there is something you have to keep in mind when working with messages (RMessage2):

If a client makes an asynchronous request to the server. The server signals completion on the RMessage2 instance (message 1) when he has finished the asynchronous request. For cancellation of this asynchronous request the client can send another request to the server (message 2). This completes immediately and forces the server to shutdown/cancel all its outstanding requests. After this has been done the server signals message 1 for completion. For making all this working the server has to store a copy of the message 1 and not a reference/pointer! By the way the type RMessage2 is a handle to a kernel side message instance.

CBase derived member variables

2007-05-31T11:27:00.000+01:00

A CBase derived member variable has to be cleaned up correctly. If it is a member variable of another CBase derived class it has to be cleaned up in the class's destructor via a call to "delete iMember;" this works correctly without any checks independently if the pointer owns memory or is NULL.

CBase derived members are zero initialized during construction of the owning CBase derived class. If a non CBase derived class owns a CBase derived member the pointer has to be zero initialized explicitly (commonly in the constructors initialization list) and the owned resources have to be freed in a Release/Close function by a call to "delete iMember;".

Asynchronous service provider

2007-05-23T10:12:00.000+01:00

An asynchronous service provider (ASP) has to store a reference (better is a pointer) to the callers TRequestStatus variable as its own member variable. In most cases the caller of an asynchronous function is an Active Object (AO) which has a TRequestStatus membervariable. Storing a pointer is better so it does not have to be intialized when constructing the ASP object. When calling the ASP's asynchronous function the reference/pointer to the caller's TRequestStatus is set to KRequestPending. A check can also be performed (if iCallerStatus is already set leave with KErrInUse exception). After this the asynchronous task is performed. When it is finished the ASP calls User::RequestComplete(iCallerStatus, aResultCode). In this case the AO's RunL eventhandling method is called.

RNotifier can be used for showing dialogs in non GUI apps

2007-05-23T09:51:00.000+01:00

Symbians Notifier framework is for showing dialogs in non GUI applications (servers/console apps). It provides several buildin dialogs (e.g. Bluetooth device selection) and the option to create custom dialogs (confirmations, info). Some of the Notifier dialogs you should have used without knowing that's the notifier framework behind it (e.g. User::InfoPrint, User::BusyMsg).

Pointers and references

2007-05-16T10:32:00.000+01:00

A reference can be seen as a dereferenced const pointer and a const reference is similar to a dereferenced const pointer to const. You should use pointers as arguments or return values where you can not use a reference (ownership transfer, pointer arithmetics). In every other case you should prefer a reference.

Asynchronous calls

2007-05-14T16:52:00.000+01:00

When calling an asynchronous function you should never pass arguments from the stack to that function. I can not say exactly if e.g. a TPtrC wrapped around a HBufC* member variable should be avoided.