[Development] unique_ptr and Qt, Take 2

[Иван Комиссаров]

By forcing usage of smart pointers, of course.
The moment you start writing

QWidget w1;
QWidget w2;
w1.setParent(QObjectSmartPointer<QWidget>(&w2));

It’s time to stop and think if you’re doing the right thing=) It is possible to pass an object on a stack to a unique_ptr/shared_ptr ctor, but that’s the problem of the person who's doing this, not the design flaw of smart pointers, right?

We need to make it intuitive to use smart pointer and hard to use them incorrectly. It is quite orthogonal to «support every corner case» which are QObjects on stack IMHO - there are always problems with them (except for the top-level objects).

Note, that we still need an old API for backward-compatility which works with QObjects on stack fine, so the user code won’t be broken in any case, but we might want to decide what use cases we do want to support and how users should write modern qt apps and what use cases are considered voodoo and bad practice.

> 3 мая 2019 г., в 22:15, Giuseppe D'Angelo via Development <development at qt-project.org> написал(а):
> 
> Il 03/05/19 22:00, Иван Комиссаров ha scritto:
>> Which should be considered bad practice and banned on an API level
>> QWidget w2
>> QWidget w1;
>> w1.setParent(&w2);
>> QWidget w1;
>> QWidget w2
>> w1.setParent(&w2);
> 
> Banned at an API level -- how, exactly?
> 
> Cheers,
> -- 
> Giuseppe D'Angelo | giuseppe.dangelo at 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 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/20190503/b3b4ae23/attachment.html>