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.macie...@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@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
