Reading suggestion

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

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

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

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

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

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?

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.

1. Simple answer: use vector<> for everything unless you have a real reason to do otherwise.
2. 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.