Qt World Summit: Register Today!

Deep copy of a struct containing a QWidget*

  • I have a small struct containing a pointer to a QWidget @ struct Field
    QString name;
    QWidget* widget;
    bool isOn;
    };@ Then I would like to use a QVector<Field>. However when I push_back a new Field(), I get a copy of the QWidget pointer, not the QWidget itself. The common answer to that is to implement a copy constructor and an assignement constructor.
    Both of them should perform a deep copy of the struct.
    However it looks like there is now way to deep copy my QWidget*

  • As you probably know, a copy of a pointer is just a copy of that pointer, not a copy of that what is pointed to. So, if you want a deep copy, use values in your struct instead of pointers. However, with QObject derived classes such as QWidget, you can not do that. They are simply not copyable. So, you are out of luck.

    I am wondering what you are trying to achieve with this design. Why do you want to construct new QWidgets every time you insert or retreive a value from your vector (that's when a copy occurs)? What is that supposed to accomplish? Where are you going to display those widgets?

  • I try to build a user editable list of custom fields.
    This fields could be checkbox, lineedit or combobox, etc.
    You think my design sucks?

  • So... basically, you're looking for a property editor?

    There are many examples for those to be found. The way you are going about it, is certainly not going to work though.

  • Reinventing the wheel?
    Would you have a link to one of the simple examples you are mentioning? Thanks a lot!

  • There are a few property editors to be found in the widgets section of qt-apps.org, but there is also one in Qt Designer that you may be able to leverage. I personally used (and extended) Yape from there.

  • I do not see a problem using and filling QVector<Field>.
    A field element holds a pointer to the widget and assumes ownership of the widget. So you have complete control over the widget. Of course the widget can not be moved from the location where it was created into the QVector, but why would you insist that this happens?

  • [quote author="dialingo" date="1310031616"]I do not see a problem using and filling QVector<Field>.[/quote] When you insert a new Field to the QVector @QVector<Field> fields;
    fields.push_back(Field());@ A Field will be created, then it will be copied in the QVector calling the copy-constructor, and eventually the original Field is deleted. Hence if ~Field() delete the QWidget*, then my QVector contains a FIeld with an invalid pointer to a destroyed QWidget*

  • The destructor of class Field only deletes the widget if you call that in the destructor, e.g. you need this code:

    delete widget;

    As long as you do not have this, the widget is not destroyed.

  • Sure, but I need to destroy the widget or I will have memory leaks.
    I could keep a list of widgets and call a destructor on it when closing the application, but this does not sound like a nice idea.

  • You could use a [[Doc:QSharedPointer]] for this:

    bq. QSharedPointer will delete the pointer it is holding when it goes out of scope, provided no other QSharedPointer objects are referencing it.

    Edit: fixed doc link; Andre

  • Maybe memory management is much easier.
    You create a widget like this:
    @QWidget *widget = new QLineEdit(mainWindow);@
    Note that the widget is a child widget of the MainWindow
    Field field;
    field.name = "a line edit";
    field.isOn = true;
    field.widget = widget;

    QList<Field> fields; // prefer list over vector
    When you pop a field from the list the widget will not be deleted automatically. Implement Volkers suggestion if you need automatic deletion of the widget. Forgetting to delete a widget will not cause a memory leak because all widgets have a parent.

  • Thanks a lot to all of you guys!

  • you could also use a QList<Field*> or a QVector<Field*> then you dont have to take care about copying. you can implement a destructor to delete the Widget in Field, and delete the field when you dont need it anymore

Log in to reply