Confused about Namespaces, auto-generated code by Qt Creator and some C++ syntax
-
wrote on 28 Dec 2011, 23:09 last edited by
Now, onto the real problem you are having, which is simply a result of the slight difference in the way the book and Qt Creator implement the Private Implementation pattern. In the book, your class inherits from the UI class; in the code generated by Qt Creator, your class has a private member that implements all the UI stuff. So, when using Qt Creator to follow the book's examples, anytime the book references a widget as though it's just a member variable, e.g. @void FindDialog::on_lineEdit_textChanged(const QString &text)
{
findButton->setEnabled(!text.isEmpty());
}@ your code has to instead access that widget through its private UI object, like this: @void FindDialog::on_lineEdit_textChanged(const QString &text)
{
ui->findButton->setEnabled(!text.isEmpty());
}@ -
wrote on 28 Dec 2011, 23:23 last edited by
The different approaches to use a ui file in your application are described in section "Using a Designer UI File in Your Application":/doc/qt-4.8/designer-using-a-ui-file.html of the Designer manual. Qt Creator uses the single inheritance with a pointer member variable by default. You can change it in the preferences, though.
The namespace for the ui is introduce, because usually you have the plain ui class (Ui:FindDialog) which is generated from Designer's ui file and the actual class that implements the functionality. Both usually have the same stripped name and would clash if there was no namespace.
The find dialogs UI members are dereferenced using the ui pointer: ui->lineEdit. The ui is a pointer to a regular C++ class, and it's treated as such in your code. Once uic has run and created the ui_finddialog.h file, Creator catches up its contents ans provides the usual code completion for the UI components.
-
wrote on 28 Dec 2011, 23:38 last edited by
Nowhere up to this point, I have stumbled such a usage (I mean initializing a variable before entering function scope) thanks for letting me know. But still don't get it completely, where can I read more about that? I am used to initializing between the paranthesis.
I don't feel clear enough as I am confused right now. So one more attempt for my question:
@FindDialog::FindDialog(QWidget *parent)@
is just a function(constructor) that's taking a parent argument of type QWidget pointer.
@ui(new Ui::FindDialog)@
is just
@ui = new Ui::FindDialog;@
However is that a class declaration/definition inside the FindDialog class? And what happens to the ui pointer variable it has in itself? Is it just null, dangling?
And what does QDialog(parent) mean?
I feel like I haven't learnt C++ a bit :S
-
wrote on 28 Dec 2011, 23:50 last edited by
We're talking about the class constructor here - this is different from ordinary methods. You'll find the details in every C++ introduction. You may have a look at the "C++ FAQs":http://www.parashift.com/c++-faq-lite/ too.
Regarding the ui pointer: It is not initialized to a default value (NULL would be handy), but just some space in memory is reserved. It may contain some random data and creates an invalid, dangling pointer here.
QDialog(parent) calls the constructor of your base class (QDialog) with the parent pointer as parameter.
This all is very basic C++ stuff - I highly recommend reading an introduction, especially on inheritance, constructors and member initialization stuff.
-
wrote on 28 Dec 2011, 23:51 last edited by
Chris, thank you for your explanations.
Volker, thanks for the link. I have been browsing the developer site but did not stumble that page.
I think I'll get it once I finish reading.
You both have been great, have a good day/night.
-
wrote on 28 Dec 2011, 23:51 last edited by
[quote author="sonay" date="1325115484"]However is that a class declaration/definition inside the FindDialog class? And what happens to the ui pointer variable it has in itself? Is it just null, dangling?
[/quote]
It is not a declaration or definition: it is an instantiation. It allocates a new object of type Ui::FindDialog, and stores a pointer to that object in the variable "ui". At no point within the constructor function itself is ui uninitialized (or null), because it's being set before you even enter that function.[quote]
And what does QDialog(parent) mean?
[/quote]
If you look at the documentation for @QDialog@ you will see that one of its constructors takes a pointer to a QWidget: that widget becomes the dialog's parent, and Qt will then take care of deallocating the dialog when its parent is destroyed. The call to @QDialog(parent)@ in the constructor simply makes sure that the QDialog is properly constructed with the correct parent widget. -
wrote on 28 Dec 2011, 23:56 last edited by
Volker, I was just worried about the uninitiated pointer. Random data access due to faulty pointer initialization may cause segmentation fault, right? So this didn't feel right for me, I was just checking. Thanks for clarifying.
-
wrote on 29 Dec 2011, 00:01 last edited by
[quote author="Volker" date="1325116217"]
This all is very basic C++ stuff - I highly recommend reading an introduction, especially on inheritance, constructors and member initialization stuff.[/quote]
I don't know what you have read when you were learning but I have read a lot and not one of the books had this kind of initialization. I am sorry to bother you with such basic questions, you may just ignore me. Surely I will study the links you provided. Again, thanks for all your help.
-
wrote on 29 Dec 2011, 00:06 last edited by
[quote author="Chris H" date="1325116308"]
It is not a declaration or definition: it is an instantiation. It allocates a new object of type Ui::FindDialog, and stores a pointer to that object in the variable "ui". At no point within the constructor function itself is ui uninitialized (or null), because it's being set before you even enter that function.[quote]
And what does QDialog(parent) mean?
[/quote]
If you look at the documentation for @QDialog@ you will see that one of its constructors takes a pointer to a QWidget: that widget becomes the dialog's parent, and Qt will then take care of deallocating the dialog when its parent is destroyed. The call to @QDialog(parent)@ in the constructor simply makes sure that the QDialog is properly constructed with the correct parent widget.[/quote]I am sorry, I am not a native speaker. I meant what happens when you instantiate and was confused at that moment, now I got my answer. It is obvious I need to study more instead of keeping you busy. Thanks for your kind and patient answers.
-
wrote on 29 Dec 2011, 09:49 last edited by
[quote author="sonay" date="1325116861"]
I don't know what you have read when you were learning but I have read a lot and not one of the books had this kind of initialization.[/quote]Actually you should always[1] prefer initialization lists over assignments, as it allows the compiler to construct most objects in-place without a temporary object which results in better performance.
[1] "C++ FAQ 10.6":http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.6
-
wrote on 29 Dec 2011, 21:35 last edited by
Thanks, Lukas. Volker already kindly provided the link and I am studying the whole FAQ. Better yet, I have sent an e-mail to volunteer to translate in Turkish.
12/13