I know that, in Qt, parent object takes ownership of its child objects. However, if I have my own class deriving from a Qt class, do I need to control memory in my derived-class' destructor or does Qt do it for me? Below is an example:
#include <QWidget>
#include <QPushButton>
class MyWidget: public QWidget{
public:
MyWidget(QWidget* parent = 0): QWidget(parent) {
this->setAttribute(Qt::WA_DeleteOnClose);
m_button = new QPushButton(this);
}
~MyWidget() { delete m_button; } // do I need this to prevent leaks?
private:
QPushButton* m_button;
}
So my question is, do I need ~MyWidget() to prevent memory leaks? Or would QWidget somehow manage the memory for me?
No you don't, QObject handles that. Everything derived will be collected as long as it is in a parent-children tree. QWidget inherits QObject and you inherit QWidget. So you are all set.
Note that there are still many Qt types which do not inherit QObject. Better look at the doc to be sure.
Related
I would like to know if I should define a destructor of a derivate of QWidget.
Example
class CustomWidget : public QWidget{
QLabel* field;
CustomWidget(QWidget* parent) :
QWidget( parent ),
field( new QLabel(this) ) {};
}
I've already read about the "Widget tree" that will call the destructor of all the child if the parent is destructed, but i mean, just to be sure
For the given one, no. The parenting system will take care of field. But u should add Q_OBJECT macro.
The MainWindow code generated by QtCreator says:
namespace Ui {
class MainWindow; // forward-declare Ui::MainWindow (?)
}
class MainWindow : public QMainWindow // Declare MainWindow class (Ui::MainWindow?)
{
Q_OBJECT
public:
explicit MainWindow( QWidget *parent = 0 );
/**/ ~MainWindow( void );
// ...
private:
Ui::MainWindow *ui;
// ...
};
main() does:
MainWindow w;
w.show( );
MainWindow::MainWindow( QWidget *parent ) does:
ui( new Ui::MainWindow ) // Initialization
I don't understand why a MainWindow instance has a pointer to another/a different/a new MainWindow in its ui instance variable. I instrumented the MainWindow::MainWindow constructor, and I can see it's only being called once. So presumably that's the automatic variable on the stack in main(). But what about the ui( new Ui::MainWindow ) that happens in the constructor? That's creating a MainWindow on the heap, isn't it? How is it being initialized?
Maybe the subsequent ui->setupUi( this ) in the constructor is doing some magic? Otherwise, it seems like this would recurse to stack crash, as each new MainWindow creates a new MainWindow to populate its ui instance variable.
The Ui::MainWindow class is code generated by uic from the respective QtDesigner file.
It is not a widget but a helper that contains code to populate a widget.
So in your case it is code that is used to populate a QMainWindow derived class named MainWindow.
Ui::MainWindow is held as a pointer to allow forward declaration and avoid build dependencies of code including MainWindow's header to the generate code (which will change everytime you change something in QtDesigner)
There are two different classes in play here:
::MainWindow
::Ui::MainWindow
I wouldn't go so far as to say they are not related - but they are not the same class.
I a project of mine, written in Qt, I have a QWidget Widget that should display either a MyTreeWidget (inheriting from QTreeWidget) or a MyTableWidget (inheriting from QTableWidget)
Constraints
Widget shouldn't know who it is talking to. Therefore it must (??) own a class inherited by the My(Tree|Table)Widget
MyTreeWidget and MyTableWidget share a lot of code and I don't want to copy paste this code. So I thought of making them inherit from a MyGenericView which inherit from QAbstractItemView
The Interfaces
#include <QAbstractItemView>
#include <QTreeWidget>
#include <QTableWidget>
class MyGenericView : public QAbstractItemView
{
Q_OBJECT
public:
MyGenericView();
};
class MyTreeWidget : virtual public QTreeWidget,
virtual public MyGenericView
{
Q_OBJECT
public:
explicit MyTreeWidget(QWidget *parent = 0);
};
class MyTableWidget : public MyGenericView, public QTableWidget { ... };
class Widget : public QWidget
{
Q_OBJECT
public:
explicit Widget(QWidget *parent = 0) :
QWidget(parent)
{
m_genericView = new MyTreeWidget();
}
private:
MyGenericView *m_genericView;
};
The Error
erreur : invalid new-expression of abstract class type 'MyTableWidget'
m_genericView = new MyTableWidget();
note: because the following virtual functions are pure within 'MyTableWidget':
class MyTableWidget : public QTableWidget, public MyGenericView
And the same for MyTreeWidget.
So how would you correct this?
It seems that what you're trying to do is ill-advised. Both views that you derive from are convenience views. They hopelessly mix up the view with the model. It's OK to use them if the needs are simple and convenience is all you're after, but in your case I presume most of the shared code is related to the model side of things, not to the view. You could probably achieve what you wish by simply showing a QStandardItemModel on either a stock QTableView or a stock QTreeView, and having a class that uses the QStandardItemModel to build up your data structure.
For more details of how you could do it, if it turned out to be the right thing to do, see this answer.
Edit : As suggested below in comments, this answer is based on faulty assumptions. Please see the better answer below.
First, you have an issue of diamond inheritance. Your error is because MyTableWidget has an undefined pure virtual member function.
Frankly though, I'm not sure why you want to use multiple inheritance at all here. If it's to save on code duplication, why can't MyTreeWidget and MyTableWidget share behavioural elements via composition instead of inheritence? Is this definitely a case of is-a vs has-a? If it's code specific to widgets that is shared but don't overlap in any way with the QTableWidget/QTreeWidget approach, just write an adaptor class that will be filled with either a Tree or Table widget.
I'm fighting with Qt. Cannot find out reliable solution for my specific problem.
We have custom class MyWidget that must:
be derived from QWidget to override closeEvent method
have fields that must be initialzed in constructor
Problems:
QWidget's guts initialized with QUiLoader from .ui file. So I have only QWidget* pointer
QWidget is non-copyable.
QWidget has no move constructor
The code (error checking and memory management are omitted for simplicity):
class MyWidget : public QWidget
{
bool m_Closed;
public:
MyWidget(QWidget* qw) :
QWidget(*qw), // error: copy constructor is private
m_Closed(false)
{}
bool IsClosed() const { return m_Closed; }
virtual void closeEvent(QCloseEvent *) override { m_Closed = true; }
};
QFile file("main.ui");
QUiLoader uiLoader;
MyWidget* uiMain = new MyWidget(uiLoader.load(&file));
uiMain->show();
Questions:
How can I workaround this? I feel that solution is very simple.
Can I use move semantics here somehow?
Note that:
I cannot make QWidget member, as I need to override its method.
Probably, I can make some MyWidget::Init() method, to init those bool flag, which must be called after each instantiation. But I find this solution unreliable.
In the end, I must just have QWidget, that I can check if it was closed or not (maybe you know another, simple way)
I use MSVC 2013 RC and GCC 4.8.1, so C++11 solution would be great
Do not hesitate, I appreciate any suggestions and criticism.
.ui files can use custom classes that derive from QWidget, so you can use your class in the Designer - even without writing any Designer plugins (it won't be shown). Right-click on a widget and select "Promote".
You need to create your own derived version of QUiLoader, and provide an implementation of the factory method QUiLoader::createWidget that can create your widgets. See this answer for a complete example.
Then you put your initialization code in the derived widget.
I have several different classes derived from QGraphicsItem or its children (like QGraphicsRectItem). I am at the point when I need to copy selected objects of those classes while not knowing exactly which one I copy.
Since QGraphicsScene::selectedItems() return a list of selected items I decided to use it, however I cannot copy the QGraphicsItem since its an abstract class. To address this I am trying to copy the object using malloc and memcpy.
MainWindow.cpp
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
scene = new QGraphicsScene();
item = new QGraphicsRectItem(50,50,50,50);
item->setFlag(QGraphicsItem::ItemIsSelectable);
scene->addItem(item);
item->setSelected(true);
ui->graphicsView->setScene(scene);
}
MainWindow::~MainWindow()
{
delete ui;
}
void MainWindow::on_pushButton_clicked()
{
for(QGraphicsItem *item : scene->selectedItems())
{
QGraphicsItem *copiedItem=(QGraphicsItem *)malloc(sizeof(*item));
memcpy(copiedItem, item, sizeof(*copiedItem));
copiedItem->moveBy(50, 50);
scene->addItem(copiedItem);
qDebug() << item;
qDebug() << copiedItem;
}
}
MainWindow.h
namespace Ui {
class MainWindow;
}
class MainWindow : public QMainWindow
{
Q_OBJECT
public:
explicit MainWindow(QWidget *parent = 0);
~MainWindow();
QGraphicsScene *scene;
QGraphicsRectItem *item;
private slots:
void on_pushButton_clicked();
private:
Ui::MainWindow *ui;
};
GUI consisting of QGraphicsView and QPushButton is sufficient for this example.
This code seem to work, item and copiedItem have different addresses but the same properties as qDebug() returns.
The scene however return the following error:
QGraphicsScene::addItem: item has already been added to this scene
I don't quite understand why the scene thinks the items are the same while they have different addresses. Is there any way to solve this issue?
EDIT:
If possible I would like to do this without modifying the code of classes derived from QGraphicsItem, since this is a group work and I would not like to bug other functionalities.
If you look at the class definition inside qgraphicsitem.h, you'll see the following:
private:
Q_DISABLE_COPY(QGraphicsItem)
Q_DECLARE_PRIVATE(QGraphicsItem)
What this means is that, by design, you are not supposed to copy a QGraphicsItem, each object is supposed to be unique.
EDIT:
I would imagine that the reason that you are denied the copying ability is because QGraphicsItem follows the Composite Design Pattern. Creating a copy of a single object that has child items would result in child items having more than one parent. To get round that, you'd have to not only copy the item you're interested in but every child in the child hierarchy as well. For very large hierarchies, this can become a very time-consuming operation.
If you really feel that you need to make copies, you can create a cloning factory function/class that creates a clone of the QGraphicsItem and all it's children by going through all the object's properties and transferring them to a newly created QGraphicsItem.
If this is not feasible, perhaps think about accomplishing your goal in a different way.
You really want to be using the copy constructor or the assignment operator, not malloc and memcpy. This is how you copy objects in C++:
QGraphicsItem copiedItem = *item;
The problem of copying a class by block copying its memory with malloc is that if the class contains pointers to objects or arrays, then only a shallow copy will occur.
In your case of getting pointers to a QGraphicsItem, you'll need to identify the type of item you're copying (its actual child class, not base class) and use the copy constructor. QGraphicsItem includes a function called type(), which returns an int that indicates which item it is. You can also add to this in your own derived classes by implementing the type() function. For example, from the Qt docs: -
class CustomItem : public QGraphicsItem
{
...
enum { Type = UserType + 1 };
int type() const
{
// Enable the use of qgraphicsitem_cast with this item.
return Type;
}
...
};
Alternatively, if all the classes are your own type, you could use your own system.
Once you know the type, you can then copy the item with its copy constructor: -
// Example, assuming type denotes a QGraphicsItemRect
QGraphicsItemRect rect = (*originalRect);
Note that if you have inherited from QGraphicsItem and added members that are pointers, you'll need to add your own copy constructor to ensure a deep copy occurs, instead of a shallow copy.