Some time ago I programmed a GUI with QT Designer / QT Creator.
For this question I will first state a schematic of how the general process of creating a GUI with the mentioned IDE works:
Creating the design with the QT Designer -> Get .ui files
The .ui files are translated into header files and you especially get something like "UIbasisclass.h" (with class UIbasisclass) .
You create something like an "UIsubclass.h" (with class UIsubclass) yourself making one private member UIbasisclass ui.
Code within class UIsubclass:
...
private:
Ui::UIbasisclass ui;
...
Finally you will create an object of UIsubclass in the main method -> Code:
...
UIsubclass *MyGUI = new UIsubclass();
...
where the constructor of UIsubclass consists among other code of:
...
ui.setupUi(this);
...
In short: We have a UIsubclass that is mostly responsible for applicational methods, but also has a private member of UIbasisclass named ui that consists mostly of design code.
When we create an object of UIsubclass its private member UIbasisclass ui is initialized within the constructor of UIsubclass with the object of UIsubclass itself (?). [see: this pointer]
My questions are now:
Why isn't there used inheritance in the way that UIsubclass inherits from UIbasisclass? Instead one object of UIbasisclass becomes member of UIsubclass.
Is this some specific advantageous concept (if yes which advantages has it or how is it named?) or is it "just" a necessity of the QT code structure?
Let me know if I have to specify my questions or if there are any questions.
You can do with private inheritance, it is even documented in Qt documentation.
The use of a private member for ui is the default because of the templates used by Qt Creator, Qt itself does not care.
Why isn't there used inheritance in the way that UIsubclass inherits from UIbasisclass?
You're asking us about why you didn't do it in your own code? Just do it. It's up to you. It truly is your code. You are responsible for its design. If you're using a template, it's there to help you get started, but not to design your software for you. The responsibility is yours, and yours only.
it "just" a necessity of the QT code structure?
There is no such necessity. The Ui class is a POD class with a bunch of pointers and one method. Nothing much to it. If you want to privately inherit from it: go right ahead.
Because with a private member you can forward declare the generated class:
namespace Ui {
class MyForm;
}
class Foo {
private:
Ui::MyForm *ui;
};
and on the .cpp file you insert the include.
this way all of the possible includes of this file will not have to preprocess that file again.
Related
My experience in c++ is very limited, so I excuse if my question is dumb or elementary. Here goes:
When doing larger project in a language like c++, and you possibly have a very big line of inheritance, is it normal practice to include every single derived class in the.. main file, let's say.
Is there some way to circumvent this, or am I missing something banal?
Thank you.
For a C++ program to use a C++ class, it requires the declaration. If the class inherits from base classes, then those declarations are required to process that class declaration. This applies recursively: the entire inheritance tree of the class is required.
If the inheritance graph is so deep and broad (perhaps due to multiple inheritance) that the project decides it is unacceptable, then it has to be restructured. Classes might be able to use aggregation instead of inheritance. So that is to say, instead of:
#include <widget.h>
class foo : public widget { ... };
it may be possible to have;
class widget; // "forward" declaration only; no #include needed
class foo { widget *pwidget; ...}
Now, only the file which implements foo needs the full declaration of widget; the clients of foo which are including "foo.h" don't need it.
But now foo is not a-kind-of widget any longer, which has implications on the code organization. foo still has the widget parts by way of creating an object and holding it. If widget conforms to some abstract interface for widgets, foo may be able to implement that, and delegate to the contained widget.
Another tool in minimizing dependencies is dependency inversion.
As Qt programs happen to live within their MainWindow class, I am having troubles altering the design components via a member class, that, because of inter-inclusion of headers leading to compilation errors.
MainWindow class holding a EventManager member object needs to have its design components modified in a method of EventManager without having multi-inclusion issue, that considering that MainWindow needs to include EventManager to be able to hold it within its class as member.
What would be the best (programmatically speaking) method to achieve this goal ?
I am using QT4.8.4 + Qt Creator 2.8.1. Now I need to create several classes Child_X that inherit from another class Parent. In Parent I have several virtual methods.
Now I have to implement them in all of my Child_X classes. To save editing time, I'd like Qt do that for me automatically. When I remember right there is the possibility to have Qt create all the virtual methods. Does anybody know how?
Thank you
Sorry, I did not formulate correctly: I did not mean that Qt will automatically write the body of the methods. ( To invent that would probably make you very rich :-) )
I was talking about Qt writing all the headers of the virtual methods in the newly created (inherited) class. This saves a lot of writing/copying classnames etc.. The body would be empty in all the virtual methods.
Thank you
itelly
I hope you already found it, but maybe for others:
Right click on the class name in the editor.
In the menu, click on 'Refactor' and then on 'Insert virtual functions of base classes'.
You can choose to directly make the functions in the implementation file (as well as in the header file).
there is the possibility to have QT create all the virtual methods
There is no such possibility, because Qt can't read your mind and divine what those implementations are supposed to do.
Speaking of that - what are your virtual methods supposed to do? Please edit the question to fix that.
I am writing an application of middle size. I will have many gui components and many classes. However, it is difficult for me to organize the code, to separate the logic, ... For example, let say that I press one button that creates an object of a class and perform a computation on that object. After exiting the slot function of the button, this local object is destroyed. What if I need it in another function later? Defining everything as a global variable in the header file is not a good thing for me. So I was thinking of a static class that contains somehow pointers to all the objects I will need later. Does anybody has a better idea?
How to manage objects inside an application is always a tricky
question. Qt goes down a very object-oriented route and uses reference
semantics implemented through pointer for nearly everything. To
prevent tedious manual memory management Qt organizes everything into
Object Trees. This
is augmented by Qt own
object model that adds
some dynamic capabilities.
If you want to go down that route, stick to everything Qt provides. It
is much more similar to Java than the usual C++ approach and might be
more comforting for beginners and maybe suits your application
domain. It tightly ties your code to Qt and will make it hard to
separate from it.
One other approach means to simply forgo all Qt stuff and work out the
core logic of your application. Develop it in pure C++ and than have a
thin layer that ties this logic into your Qt application through
signals and slots. In such an approach you would opt to use more
value-semantics.
For your concrete example of creating an algorithm and keeping it
around. The Qt approach:
class MyAlgo : public QObject {
Q_OBJECT
public:
MyAlgo(QObject* o) : QObject(o) { }
virtual compute();
};
// use it in a mainwindow slot
void MainWindow::executeAlgorithm(const QString& name) {
MyAlgo* algo = this->findChild<MyAlgo*>(name);
if(!algo) {
// not found, create
algo = new MyAlgo(this); // make mainwindow the parent of this algo
algo->setName(name); // QObject name property
}
algo->compute();
}
I'm developing a Qt application. For each class, I'm trying to mimic the framework, such as error() and errorString() method, use of Private implementation.
But I would like to add a per class debugging:
Set a macro to the desired level of debug,
have a macro or a function that knows the level of debug, and use qDebug() or qWarning()
which is class independant, and will know the current class's name (for some pretty prints)
Anyone have a good idea to implement this ?
Maybe the QxtLogger class, part of the Qxt library (an extension library for Qt) provides what you need.
I would definitely consider using something already existing and tested rather than implementing my own logging solution.
You may write a class, for example CDebug with all needed debug methods, and use it in other classes, like:
class CMyDialog : public QDialog, public CDebug {...};