Recommend memory management literature

[frenk_castle]

This is not all Qt question but I would appreciate if you could recommend to me some literature on the following subjects. You will save me the time of sifting through to much books or online documents trying to find answers. Again I tried to be very specific but if I wrote to much I apologize.

I am interested in some good documentation of the parent role in memory management. To read exactly how it is done. I believe it will help me understand the process of memory management in Qt better and help me write better code.

Since I haven't read any good documentation on memory management namely stack and heap I would appreciate recommendation on those topics as well.

I don't know if these terms are C++ bound or Windows bound or both, or are they independent from operation system and programing language.

I have decent experience in ISO C++ and I have recently started to learn Qt, but I am electronics engineer by trade not a programmer so my question might be formulated wrong or just be plain stupid.

To help you understand I will give you an example.

I gathered most of my C++ knowledge from Stanley Lippmans book C++ primer.I read the book some time ago so if I write something wrong it is because I either forgot what the book said or because I understood it wrong in the first place. In the book he writes about two ways of making an object. I will use int in my example for simplicity



int i(2);
int j = 3;


In the case of object i the compiler will reserve the memory for object i and fill it with the appropriate value. In the case of j the compiler will reserve the memory for j but will fill its memory space using the default constructor. Then it will create the temporary object of type int, I believe on heap but I am not sure, and then use assignment operator which in turn usually uses copy constructor to copy that temporary object into j. In some cases this might be relevant. Maybe I created the type which uses the copy constructor in its assignment operator. And maybe the copy constructor doesn't create an identical copy because my type has to work like that. It is very important how I create object of that type then.

To further the subject a little. I have decent knowledge of assembler languages, not just the Intel compatible CPUs but many microcontrolers, and it helps me to know how my code is executed machine wise so to speak. I know that some of you might frown on this but I believe this is good stuff to know.

To try to explain why. I started Microsoft course on C# today. My company paid for some of us to go on this course. We had to do an exercise which consisted of making a simple form making two classes and using some getter and setter methods manipulate those classes. The constructor for bankAccount class was


public BankAccount(string userName, int userBalance)
{
name = userName;
balance = userBalance;
}


The default constructor was



public BankAccount() : this("unknown", 0)
{
}



This is C# code don't be confused. When I asked our instructor can I write


public BankAccount(string userName, int userBalance) : name(userName), balance(userBalance)
{
}


because every professor on college and mister Lippman in his book made the remark that constructor from the last example initialize the members of the class, while the one from the first example initialize them using the default constructor and then uses the assignment operator and in most cases copy constructor to copy the values passed to the objects constructor.

The instructor either didn't know what I am talking about or refused to explain and just said you can't write the constructor like that you have to you the first one.

I went on this course not because I have much interest in C# but because it was free. If my company is willing to pay for me to learn something that might be useful for me I am not going to say no. But C/C++ is, in my humble opinion, still by far the best programing language I had the chance to program in. So I think that learning about stack, heap and Qt parenting methods for memory management will help me become better. So if you could recommend me literature on these topics I would appreciate it very much.

Thank you in advance. Sorry if my post was to long and if my english is not very good.

[wysota]

I am interested in some good documentation of the parent role in memory management.
The "parent" thing is strictly Qt specific. The parent simply deletes all its children from its own destructor.






int i(2);
int j = 3;


In the case of object i the compiler will reserve the memory for object i and fill it with the appropriate value. In the case of j the compiler will reserve the memory for j but will fill its memory space using the default constructor.
Actually no. The two calls are exactly equivalent. I believe you meant this situation:

int j;
j = 3;


Then it will create the temporary object of type int, I believe on heap but I am not sure
On the stack or in the cpu register in that case as ints can be stored in registers and addressed as immediate values (which simply brings speed).


, and then use assignment operator which in turn usually uses copy constructor to copy that temporary object into j.
PODs don't have constructors, they are not classes.


Maybe I created the type which uses the copy constructor in its assignment operator. And maybe the copy constructor doesn't create an identical copy because my type has to work like that.
That's your problem, then. If you want to shoot yourself in your foot, you're free to do it but don't blame others afterwards.

[frenk_castle]

First thanks for your answer. I was starting to think that nobody will answer. Second sorry for posting in the wrong topic.

Concerning parent role I am aware it is a Qt thing. What I found on the web is pretty much when parent destructor is called it goes though the list of its children and deletes them all. I was hoping to find something more detailed but this will have to do.

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.

I don't know if it is legal to type part of the Lipmmans book so I will try to make my own example.

Let say that we have created class Book.




class Book
{
public:
Book(std:string);

private:
std::string sName;
};

//Constructor version one

Book::Book (std::string name) : sName(name)
{
//some code
}

//Constructor version two

Book::Book (std::string name)
{
sName = name;
//somecode
}


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. I was trying to write about this in my previous post but I failed and I apologize for that.

Wysota, sorry for putting you on the spot like this I mean no disrespect, but you are no doubt much better programmer than me. And things like this are probably trivial to you. 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.

What I know are two things:

1. Proper memory management is important. Most runtime error occur because of improper memory management.

2. I don't know how to manage memory correctly.

I am currently working on an application which need to dynamically manage list of Job object that I will create. Idea that I have and this is just and idea because I will probably find better ways to implement the final desing is following.

Every job object should be some king of widget that has internal data, buttons for opening the dialogs for changing jobs internal data, tree view to show that internal data after the successful change. All job objects should be in a container in something that should be like a parent layout. Parent layout should have button to add new job, button to delete the last job from the container. Also parent layout should draw only the jobs that exist. When the job is deleted it should be removed from the window. The parent layout for job objects should look something like this and be part of the larger window:



| |
| AddJobbutton RemoveJobButtom |
| |
| |
| ________________ |
| | | EditJobButton11 |
| | TreeView1 | EditJobButton12 |
| |_______________| |
| |
| ________________ |
| | | EditJobButton21 |
| | TreeView2 | EditJobButton22 |
| |_______________| |
|_________________________________________________ |



I don't know how to done this right. 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. Most probably the container in which I decide to keep my Job objects will deal with this.



if ( container.size() < maxSize) //One of Qt container class haven't decided yet which one is the best for my application
container.add(new Job);
if ( !container.empty()) //Probably don't need to check this
container. delete();


If I am boring and annoying I apologies. I am just trying to learn and I am aware that most of my questions are not very interesting for you. And by you here I don't me only Wysota but all of the experience programmers on this forum. You know all this stuff. I, on the other hand, am still learning.

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.

Sorry if my post was to long. Thanks in advance.

[wysota]

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 :eek:


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.