Question on QLineEdit Style

[wysota]

I really miss discussions such as this one, thanks

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

QObject o1;
QObject o2(&o1);

QObject o1;
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

[d_stranz]

I really miss discussions such as this one, thanks

Yeah, they are much more fun than "Why doesn't my program work? See if you can guess, because I'm not posting any code."

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

Yes, point taken. I thought about that as well - a good number of the posts here are programming errors that are essentially equivalent to that example - allocate something on the stack, pass it to another QObject as a child or parent by dereferencing it, then it goes out of scope, and either it goes BOOM! or nothing happens as expected.

But that leads to more rules and more exceptions to rules, and before you know it you've written another Qt book.

Two of them (out of three? four?) said it was lack of garbage collecting.

Then they haven't discovered boost::shared_ptr<> yet.

At the cost of a little performance hit, it has saved me days of tracking down memory problems and has allowed me to write programs containing tens or millions of shared objects. It's the closest thing to garbage collection you can find in C++, in my opinion.

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.

I'm not sure that LGPL has all that much to do with it. (Or are you referring to this forum? I think the problem here is that too many people are finding out about it) .

Probably it has more to do with the availability of cheap PCs, free compilers and development environments, and people coming into the field at much younger ages and no experience. Even though my programming was self-taught, all I had to rely on back then was books - there wasn't much in the way of Internet in the '80s and '90s, and certainly not the tidal wave of online code you can find today. Now, if you want an algorithm to do "histogram-based image segmentation", well Google will give you page after page of hits. No need to understand why it works, just download the code and compile it.

Likewise for new people learning to program. It really isn't necessary to "learn" at all - you download an example, hack at it until it does what you want it to do, but you really haven't learned how to program. You're just a monkey with a typewriter, and sometimes by accident, you get something that works. And if you can't get it to work, you make a post here and hope that someone will get it to work for you.

"Sunday Developers"

Hey! I'm a Sunday developer! (and also Monday, Tuesday, Wednesday, Thursday, ...)

[wysota]

Yes, point taken. I thought about that as well - a good number of the posts here are programming errors that are essentially equivalent to that example - allocate something on the stack, pass it to another QObject as a child or parent by dereferencing it, then it goes out of scope, and either it goes BOOM! or nothing happens as expected.

Just let's be clear again -- the code I posted is correct. For instance:

QMainWindow mw;
QDialog loginDialog(&mw);
if(loginDialog.exec()) {
 // ...
}

QMainWindow mw;
QDialog loginDialog(&mw);
if(loginDialog.exec()) {
 // ...
}

To copy to clipboard, switch view to plain text mode 

or more explicitly to avoid problems with broken compilers:

QMainWindow mw;
{
  QDialog loginDialog(&mw);
  if(loginDialog.exec()) ...
}

QMainWindow mw;
{
  QDialog loginDialog(&mw);
  if(loginDialog.exec()) ...
}

To copy to clipboard, switch view to plain text mode 

Then they haven't discovered boost::shared_ptr<> yet.

Unfortunately using smart pointers is not possible in every situation. I personally don't have any issues with memory management in C++ (even without using smart pointers).

I'm not sure that LGPL has all that much to do with it.

It's easy to explain. In the "pre-LGPL" era of Qt, you had to either pay for Qt (which was quite expensive, especially for people living in developing countries) or make your program open source (when using the GPL variant of the licence). Either way Qt was usually not the first choice for people wanting to write their first program but were rather used by companies and programming enthusiasts with a decent knowledge of C++. When LGPL came, Qt became accessible for virtually anyone in the world to use for pretty much anything. This caused a flood of would-be programmers from China and India as well as other Middle East countries. You can see that most of issues brought up here or on other forums related to Qt has nothing to do with Qt but rather with compilers, operating systems, low-level system API and of course C++.

[high_flyer]

@d_stranz
All is well and good - however, my point from the start didn't change, nor anything you say will change its validity:
The decision of allocating an object on the stack or heap does not depend on its type - which is what you rule essentially says.
Even if you found the rule helpful, it doesn't make it correct - and if you are a beginner reading your post, and you get used to that way of thinking, you will have hard time understanding why all of the sudden your application crashed, due to the fact you allocated something on the stack and not on the heap due to your rules, which lets say - due to scope issued was nonsense.
And having hard time to understand what the problem is was basically what you set to avoid from the start.
Making your life easier by using a principally wrong rule just shifts your problem to another time and complexity domain.
I too am not programming since yesterday, and I found out, that it pays more to start slow hard and correct, then fast easy and incorrect.