That’s exactly the problem we’re discussing here.
Consider this example (was writing without a compiler, might be typos)
class MyWidget : public QWidget
{
QWidget container; // note, doesn’t require explicit parent, layout handles
that
QLabel label;
public:
Widget(QWidget *parent) : QWidget(parent), childWidget(&container)
{
auto layout = new QMyLayout(this);
layout->addWidget(&container); // is ownership transferred here?
label.setText(«Hello»);
}
};
Who owns label? Is the ownership truly unique here? Is it shared? It’s
something in-between - container thinks that it owns a label but in fact it
does not, the real owner is MyWidget.
Note, that this worked for ages and people are using this idiom to save one
extra allocation, plus it requires less typing. And this is intuitive. But that
doesn’t exactly the «QObject deletes his children» idiom.
Maybe we need something like «maybe owner pointer» which has a ptr to an object
and bool if it should delete it or not. This pointer can be constructed from
reference (aka «on a stack») with own=false. However, the semantics and the API
of such pointer is not clear for me, it’s easy to end up with another auto_ptr,
so confider this as a crazy idea.
> 4 мая 2019 г., в 0:36, Giuseppe D'Angelo <giuseppe.dang...@kdab.com>
> написал(а):
>
> Il 04/05/19 00:33, Иван Комиссаров ha scritto:
>> Back to the topic - in case we really want to support the "stack case", I’d
>> say shared_ptr is the only option (in combination with
>> enable_shared_from_this which is already a kinda part of QObject, as
>> mentioned above)
>
> QObject ownership isn't shared, it's unique. A widget is in ONE hierarchy,
> which fixes its owning native window, its coordinate system, its Z order
> amongst its siblings; not N hierarchies.
>
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
