Question on QLineEdit Style

[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.