Question on QLineEdit Style

[high_flyer]

1. If a class is derived from QObject, then usually you create it on the heap using new. If you give the new instance a parent, then the parent will delete it and there is no memory leak. You can give an object a parent in many ways:
- in the constructor: myObject = new QObject( parentObject );
- explicitly: myObject->setParent( parentObject );
- using some other method call that internally sets the parent: parentObject->addWidget( myWidget );, etc.

Classes derived from QObject always have a constructor that take a "parent" argument.

2. If a class is not derived from QObject (QColor, QFont, QPen, QString, etc.), you almost always create it on the stack: QPen myPen; and pass it into a method by reference: painter->setPen( myPen ); If you create the instance on the heap using new, then you must also delete it.

Deciding if an object should be allocated on the heap or stack has nothing and should have nothing to do with the fact its a QObject or not, or any other type of class.
However:
scope of usage, performance issues, resource issue should.

[wysota]

scope of usage, performance issues, resource issue should.

Totally agreed.

[d_stranz]

Nitpicks, you two.

Sometimes presenting a relatively simple set of rules to help guide a beginner is better. If you are trying to write your first Qt programs and just can't get it to work because you misunderstand basic Qt principles, you aren't worrying about "scope of usage, performance issues, and resource issues."

When I first started to learn Qt, one of the hardest things to understand was who was in charge of an object's lifetime and whether an object could be stack vs. heap allocated. Understanding the simple rule that "if it is a QObject then its parent will delete it" was a key to end my confusion. A large percentage of the "why doesn't this work?" posts in this forum are exactly because of misunderstanding the Qt parent-child concept and stack vs. heap allocation with respect to object lifetimes.

Once the programmer figures that out and starts having working programs, that is the time to start thinking about the nuances of performance and scope.

[wysota]

Sometimes presenting a relatively simple set of rules to help guide a beginner is better.

The problem is usually people stop at this point. Then they spread those rules without proper understanding that it is merely a simplification. They write a "tutorial", post it somewhere in the Web and then other people read it, incorrectly apply those rules they learned by reading the tutorial and come here (or elsewhere) claiming that Qt is stupid and difficult becaust it doesn't work the way they read about in the tutorial. Of course totally missing the point that Qt has nothing to do with this.

If you are trying to write your first Qt programs and just can't get it to work because you misunderstand basic Qt principles, you aren't worrying about "scope of usage, performance issues, and resource issues."

If one knows the rules of C++, those same rules apply to Qt. If they don't know the rules, they should learn them first before trying to write their first Qt program.

Once the programmer figures that out and starts having working programs, that is the time to start thinking about the nuances of performance and scope.

What I'm worried about is that this "once" often never happens.

[comuslxl]

@d_stranz
I have almost the same question when I begin my first Qt program. Your rules are helpful, and can help new Qt programmers to quickly finish their first Qt program without too many critical bugs. This's a very very good way to lead someone to the world of Qt programming.
@wysota
In fact, many books are using the same way to help programmers to gradually understand Qt. Just think about what we have learnt when we are 7,8 years old, we are told sqrt(-1) is wrong, but what about 10 years later? I think people would like to learn a certain thing step by step. If a beginner is told the danger of memory leak or some other abstract issues at their first program, they may not serious about those because they don't know what they are and how they come up. Only when they themselves witness the consequences of e.g memory leak will they keep an eye on the problem. So I think study is a process of correction. If one is STUDYING, then "once" will happen, i'm sure.

[wysota]

In fact, many books are using the same way to help programmers to gradually understand Qt.

Two facts:
1. People don't read books nowadays, they read tutorials
2. If they do read a book, they read the first chapter and then they put the book aside because they are excellent programmers now.

Just think about what we have learnt when we are 7,8 years old, we are told sqrt(-1) is wrong, but what about 10 years later?

When you are 8 years old, you do not try to calculate sqrt(-1). People do try to use everything C++/Qt offer starting from the first day of their programming life. Just read 100-200 random threads on this forum and you'll come to similar conclusions.

If one is STUDYING, then "once" will happen, i'm sure.

Yes... "if"... And yet people come here and don't know the difference between C++ and Qt or between a compiler and an IDE (e.g. "I upgraded QtCreator to 2.5.0 and now my program doesn't work"). People do not bother learning why things work the way they work if they find a "solution" to their "problem" after searching the internet for two minutes. They immediately fall into another pitfall and start browsing forums for solutions on that.