4 ms·
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 owner
by 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 agoLearn 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 agoThe 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...