3 ms·

Is Qt 5.10 still stuck in the time prior to C++11? Does it have clear pointer ownership and move semantics?

gusmd 9y ago
Qt has moved into C++11+ world for quite some time. IIRC 5.7 was an important step in that direction, and they keep moving that way. Move semantics are much better. Not sure what you mean by clear pointer ownership, though.
- inetknght 9y ago
  `unique_ptr` and `shared_ptr` semantics
  - deleted 9y ago
    [deleted]
  - gusmd 9y ago
    Qt does have QSharedPointer and QWeakPointer. Also, you can use QScopedPointer for things like implementing RAII with custom deleters, etc.
jcelerier 9y ago
There is a single rule for pointer ownership in Qt: parents own children. The problem is that it is not enforced by the compiler :p
- inetknght 9y ago
  That rule is not clear ownership. That rule is implied ownership and goes against modern C++ practices. If I give something a raw pointer, I don't expect ownership to be taken over by that something. ``` auto window_ptr = new QWindow(); auto field_ptr = new QTextEdit(window_ptr); ``` First, requiring the use of `new` is bad practice in modern C++. Second, passing ownership of `field_ptr` to `window_ptr` is unclear. Because I called `new`, I expect that I need to call `delete`. ``` delete field_ptr; delete window_ptr; ``` Ooops... now I have a double-free! I understand that Qt has been around since long before pointer ownership semantics were defined. But pointer semantics have been around for quite a long time now. The Qt Company really needs to modernize. Even if they don't want to use `std::unique_ptr` or `std::shared_ptr`, they can create their own (hopefully easily compatible) `QInstance` and `QSharedInstance` or something similar. The raw pointers everywhere and lack of clear ownership is, in my opinion, a barrier to entry. I myself am pretty timid to use Qt because of it and I've got 10+ years of C++ experience.
  - jcelerier 9y ago
    > Ooops... now I have a double-free! not in this case: when you call delete on field_ptr, it removes itself from the list of children of windows_ptr. The other case would have crashed though. But generally you don't even need to have new / delete / make_unique / whatever: class MyWidget : public QWidget { QFormLayout lay; QPushButton button; QLineEdit edit; public: MyWidget(QWidget* parent) : QWidget{parent} , lay{this} { button.setText("Hello world"); lay.addRow("Button", &button); lay.addRow("Some text", &edit); } }; these cases will work just fine since everything will be deleted in the correct order. Likewise, you can just store a std::vector<std::unique_ptr<QObject>> if it makes you sleep better at night, if the objects are child of the class in, which you're storing them. > Even if they don't want to use `std::unique_ptr` or `std::shared_ptr`, they can create their own (hopefully easily compatible) `QInstance` and `QSharedInstance` or something similar. There are already various smart pointer types in Qt. But would you really like them to add unique_ptr overloads everywhere ? I'd hate to have to do auto my_widg_ptr = std::make_unique<MyWidget>(); auto my_widg = my_widg_ptr.get(); parent_layout->addWidget(std::move(my_widg_ptr)); connect(whatever, &foo::bar, [=] { my_widg->do_stuff(); }); vs today's auto my_widg = new MyWidget; parent_layout->addWidget(my_widg); connect(whatever, &foo::bar, [=] { my_widg->do_stuff(); });
    - inetknght 9y ago
      Learn something new every day. I like this. I think my point though is still valid: that it's implicit ownership rules which are not clear ownership rules.
      - gmueckl 9y ago
        The relationships are very clear in most code using Qt. When you create a QObject-derived object, one of the constructor parameters is always the parent. Little things like this goes a long way. I never felt the need to express ownership more explicitly with Qt. Whenever I felt the urge to do so, it turned out that I was trying to do something crazy that I probably shouldn't try in the first place...

Qt has moved into C++11+ world for quite some time. IIRC 5.7 was an important step in that direction, and they keep moving that way. Move semantics are much better. Not sure what you mean by clear pointer ownership, though.

inetknght 9y ago
`unique_ptr` and `shared_ptr` semantics
- deleted 9y ago
  [deleted]
- gusmd 9y ago
  Qt does have QSharedPointer and QWeakPointer. Also, you can use QScopedPointer for things like implementing RAII with custom deleters, etc.

jcelerier 9y ago

There is a single rule for pointer ownership in Qt: parents own children. The problem is that it is not enforced by the compiler :p

inetknght 9y ago
That rule is not clear ownership. That rule is implied ownership and goes against modern C++ practices. If I give something a raw pointer, I don't expect ownership to be taken over by that something. ``` auto window_ptr = new QWindow(); auto field_ptr = new QTextEdit(window_ptr); ``` First, requiring the use of `new` is bad practice in modern C++. Second, passing ownership of `field_ptr` to `window_ptr` is unclear. Because I called `new`, I expect that I need to call `delete`. ``` delete field_ptr; delete window_ptr; ``` Ooops... now I have a double-free! I understand that Qt has been around since long before pointer ownership semantics were defined. But pointer semantics have been around for quite a long time now. The Qt Company really needs to modernize. Even if they don't want to use `std::unique_ptr` or `std::shared_ptr`, they can create their own (hopefully easily compatible) `QInstance` and `QSharedInstance` or something similar. The raw pointers everywhere and lack of clear ownership is, in my opinion, a barrier to entry. I myself am pretty timid to use Qt because of it and I've got 10+ years of C++ experience.
- jcelerier 9y ago
  > Ooops... now I have a double-free! not in this case: when you call delete on field_ptr, it removes itself from the list of children of windows_ptr. The other case would have crashed though. But generally you don't even need to have new / delete / make_unique / whatever: class MyWidget : public QWidget { QFormLayout lay; QPushButton button; QLineEdit edit; public: MyWidget(QWidget* parent) : QWidget{parent} , lay{this} { button.setText("Hello world"); lay.addRow("Button", &button); lay.addRow("Some text", &edit); } }; these cases will work just fine since everything will be deleted in the correct order. Likewise, you can just store a std::vector<std::unique_ptr<QObject>> if it makes you sleep better at night, if the objects are child of the class in, which you're storing them. > Even if they don't want to use `std::unique_ptr` or `std::shared_ptr`, they can create their own (hopefully easily compatible) `QInstance` and `QSharedInstance` or something similar. There are already various smart pointer types in Qt. But would you really like them to add unique_ptr overloads everywhere ? I'd hate to have to do auto my_widg_ptr = std::make_unique<MyWidget>(); auto my_widg = my_widg_ptr.get(); parent_layout->addWidget(std::move(my_widg_ptr)); connect(whatever, &foo::bar, [=] { my_widg->do_stuff(); }); vs today's auto my_widg = new MyWidget; parent_layout->addWidget(my_widg); connect(whatever, &foo::bar, [=] { my_widg->do_stuff(); });
  - inetknght 9y ago
    Learn something new every day. I like this. I think my point though is still valid: that it's implicit ownership rules which are not clear ownership rules.
    - gmueckl 9y ago
      The relationships are very clear in most code using Qt. When you create a QObject-derived object, one of the constructor parameters is always the parent. Little things like this goes a long way. I never felt the need to express ownership more explicitly with Qt. Whenever I felt the urge to do so, it turned out that I was trying to do something crazy that I probably shouldn't try in the first place...