[Development] unique_ptr and Qt, Take 2

Иван Комиссаров abbapoh at gmail.com
Fri May 3 23:03:53 CEST 2019


You can use the same technique in qMakeChild as in std::make_shared - to allocate MyObjectPrivate and space for the d_ptr in one go. Probably will require some additional macroses, though, to hide the implementation (sizeof(MyObjectPrivate)) in the cpp file.

I’d say it’s an implementation detail - it *is* possible to implement the creation of QObjects more efficient than it is done now without «forcing» user to use objects on stack to avoid allocations.

> 3 мая 2019 г., в 22:39, Konstantin Tokarev <annulen at yandex.ru> написал(а):
> 
> 
> 
> 03.05.2019, 23:31, "Иван Комиссаров" <abbapoh at gmail.com <mailto:abbapoh at gmail.com>>:
>> 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.
> 
> IMO it would be resonable to drop specific behavior of QObject constructor then to force unnecessary memory allocations upon users
> 
>> 
>>> 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
>> ,
>> 
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org <mailto:Development at qt-project.org>
>> https://lists.qt-project.org/listinfo/development <https://lists.qt-project.org/listinfo/development>
> 
> 
> -- 
> Regards,
> Konstantin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190503/ad3ea49a/attachment-0001.html>


More information about the Development mailing list