Quote Originally Posted by frenk_castle View Post
I was hoping to find something more detailed but this will have to do.
Qt's source code is available for public, just look there.

Now concerning me shooting myself in the foot. The example above concerning the weird behavior of copy constructor is not something I have ever done. I am aware that it is dangerous because it will lead to confusion and for almost any practical code it is down right stupid. I am not trying to be difficult just trying to understand what is happening under the hood so to speak.
Ok, but giving an argument that you might implement "i++" to pre-substract a value is not an argument for me - you want to do weird things, do it, that's your choice.

In first constructor sName is initialized using std::string copy constructor. The program then enters the constructors body and execute rest of the code. In second constructor sName is initialized using std::string default constructor. Only after program enters the constructor body and change sName value using the std::string assignment operator.
Yes, that's true. The second version is a bit slower (might be much slower depending how expensive constructing an empty object is in a particular case).

but you are no doubt much better programmer than me
You don't know that. Believe in yourself.

Like if exception is thrown during construction of an object that object is only partially constructed and is in invalid state. I only read this on the net but I don't know what to do if this happens.
That's why we tend to avoid exceptions in C++ because they are broken by definition.

1. Proper memory management is important. Most runtime error occur because of improper memory management.
Not really. Most runtime errors occur because somebody assumed something which wasn't actually true. Memory management is quite trivial these days, especially with such great tools as Valgrind and debuggers.

I am currently working on an application which need to dynamically manage list of Job object that I will create.
So encapsulate everything in a class and forget about memory management.

I don't know how to done this right.
In the first iteration make a try with something you think is fine right now. Then when you learn more about particular case, go back and redesign your architecture. The first iteration will be a prototype, the second will be a final (or almost final) result.

First version of my application will have fixed number of jobs because I don't know if I will be able to ensure integrity of my application if some "genius" user starts just adding and deleting jobs.
Don't care too much about border cases in the beginning. That's what we do testing for to discover them.

If I am boring and annoying I apologies.
No, although this post is quite long...

I am just trying to learn and I am aware that most of my questions are not very interesting for you.
If that was the case, I wouldn't be answering.

You know all this stuff.
You'd be surprised

So if you could recommend to me literature concerning proper memory management which is not out dated and hopefully is relevant for Qt development I would appreciate it very much.
You already have Lippman. That's all you need.