I really miss discussions such as this one, thanks

Quote Originally Posted by d_stranz View Post
I've been programming in C and C++ since about 1983, when C compilers first started appearing for PCs. One of the first things you learn (especially in the days of 640KB PC RAM) is that if you malloc(), you had better match it with a free() or things will quickly grind to a halt. Later, C++ taught the same thing: match up your new() and delete() or you are in for big trouble.
I'll tell you something interesting. Recently I've been interviewing people for work and one of the questions I asked them was what they considered the weakest spot in C++. Two of them (out of three? four?) said it was lack of garbage collecting. When I investigated further they couldn't say why this was so much of an issue. And those weren't some weekend programmers but rather people who programmed C++ for a living. So it seems memory management is not as big of an issue as people claim it to be. At least not for people who really know the language.

You spend days beating your head on the wall, trying to find memory leaks where you thought you had paired everything up, or looking for crashes because you did pair things up but made the mistake of using the pointer after it had been deleted. These are lessons every C++ programmer learns the hard way, and you would be lying to me if you said it had never happened to you.
I could agree that could be an issue with C but not with C++. In the latter you usually allocate memory upon constructing an object and deallocate it upon destructing the object. So it's all just a matter of proper data encapsulation. Again, not much of a deal for people who know what they are doing.

Along comes Qt. Here you have a programming paradigm where you almost always use new() to allocate a Qt object instance, but then almost never use delete() to get rid of it!
Let's be very clear here. You can delete manually but you don't have to.

Here is where I insist that the simple rule I gave is important to new Qt programmers. The simple rule explains why you don't have to call delete() on QObject instances, why you usually can't call delete() on QObject instances without bad things happening, because the rule explains who is in charge of the instance's lifetime and makes it clear that Qt isn't somehow breaking the C++ rules.
I prefer the good old rule - delete your heap data, don't delete your stack data together with allocate your objects on the heap if you want them to persist and you can't copy them and allocate local variables on the stack so that the compiler can get rid of it for you. This works with Qt and without Qt.

So, the simple rule that says, if you create a QObject instance and give it a parent, the parent takes charge of deleting it clears up a lot of confusion and gets a novice on the path to writing working Qt programs much more quickly than trying to figure it out without the rule.
You can see this thread is about what happens if you don't give it a parent. Your rule says nothing about it. Furthermore this is compliant with your rule however the result depends on compiler implementation (and interpretation of C++ standard):

Qt Code: 
  2. QObject o2(&o1);
To copy to clipboard, switch view to plain text mode 

It also helps explain why other Qt class instances can be created on the stack and can be assigned, copied, passed by value, or reused because they don't have parents and you are in charge of their lifetimes.
That's not why you can copy them. The actual rule is that they represent values and not identities and thus can be copied. That together with an explanation of what implicit sharing is makes the proper answer of why we allocate them on the stack rather than on heap (with the only exception of QModelIndex which you should never allocate on heap regardless of anything).

Yes, the rules are simple, and there are plenty of use cases where you might want to do something differently, but the average programmer will learn those things as they get more proficient. (If they don't, then they are below average, IMO).
My official point of view is that since Qt went LGPL we have been flooded by programmers who are below average and are not willing to raise above that level. Sad but true. Even more sad that Qt really requires one to understand C++ so many of such "Sunday Developers" really waste their time instead of using something that requires less knowledge to be used efficiently (e.g. Visual Basic).

I have most of the Qt books that have been written, some of them in several editions. I haven't read the first chapter and then put them on the shelf. I pretty much read them cover to cover because that's the way I learn new concepts. But one of the things that isn't adequately explained in most of these books is QObject lifetimes.
Good for you -- but you're not an average person coming here what can be seen by the proportion of questions to answers in your posts.

Take Blanchette and Summerfield's "C++ GUI Programming with Qt4" for example.
I'm reluctant to discuss this book. It is much worse than "C++ GUI Programming with Qt3". I'd like to avoid talking about work of people whom I otherwise respect. I can talk about "Foundations of Qt Development" if you please. You don't have memory leaks there