[Development] unique_ptr and Qt, Take 2

[Konstantin Ritt]

what about the other corner case:

`
~Some() {
    const auto children = someChildren();
    for (auto child : children) {
        if (!child->isDepleted()) {
            // 'detach' and let it die alone, some later...
            child->setParent(nullptr);
            QObject::connect(child, &Child::depleted, child,
&QObject::deleteLater);
            // f.i. child on a secondary thread couldn't be parented by qApp
            QObject::connect(qApp, &QCoreApplication::aboutToQuit, child,
&QObject::deleteLater);
        } else {
            delete child;
        }
    }
}
`

?

I bet that isn't that simple to do with just unique_ptr (or any other
std::<smart>_ptr). Is it?


As for beforementioned QLayout and QAction examples, sure the API could be
improved to make re-parenting obvious and to avoid resources leakage, etc.
However, unique_ptr isn't that holly bullet to solve the lazy programmer's
issues. IMO.


Konstantin

сб, 4 мая 2019 г., 2:34 Thiago Macieira <thiago.macieira at intel.com>:

> On Friday, 3 May 2019 16:14:09 PDT Иван Комиссаров wrote:
> > What I am talking about is that explicit is better than implicit. Taking
> an
> > address of an object on a stack and passing it to a function that
> (possibly
> > can) delete your object is not explicit. Wrapping that operation in a
> > construction of a smart pointer is explicit. Moving a unique_ptr is
> > explicit. When you’re «casting» your on-a-stack-QFile to a some smart
> > pointer, you’re telling the compiler (and other people who read the code)
> > «trust me, I know what I’m doing, this is intended».
>
> That I can agree with, but this goes back to the suggestion of our own
> smart
> QObject pointer classes. In non-compatibility mode, a function that adopts
> the
> passed object should only accept from another smart pointer. If you pass a
> naked pointer, it should reject and force you to clearly state that you
> know
> what you're doing.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190504/9cb53dd5/attachment.html>