[Development] The future of smart pointers in Qt API

[Giuseppe D'Angelo]

On 31/01/2020 11:07, Vitaly Fanaskov wrote:
> But how to use them in the API and which way is preferable is still
> unclear. There are two main options we have:
> 
> 1) Use std::*  smart pointers as-is.
> 
> 2) Add Qt-style wrappers around std::* smart pointers and move old
> implementations of Qt smart pointers to the Qt5Compact module.
> 
> Both options have pros and cons. It would be useful to hear your
> thoughts on it. It’s worth mentioning that some other options, like
> using Qt smart pointers as-is, were also discussed. They were found less
> suitable, but feel free to share your opinion if you disagree.

Here it seems we're just talking about the std smart pointers: 
unique_ptr, shared_ptr and weak_ptr.

My take for Qt 6 should be:

* use them as-is;
* move the Qt implementations to Qt5Compat (the Qt5 implementations are 
strictly inferior in their feature set);
* adjust the few places where a Qt smart pointer can be used to also 
take a std:: one (QVariant? C++ <-> QML bridging?)

AFAIK, there's only 2-3 usages in public APIs of Qt smart pointers, that 
would therefore need to be ported away (from the back of my mind: 
QtQuick, Qt3D in quite some deep API. Maybe QtWebEngine?)


The last smart pointer in Qt is QPointer, which is a special case, 
having obviously no std equivalent. IMO it should

1) be renamed to something more clear (suggestions welcome, or it'll be 
QObjectWeakPointer)
2) be still available under the QPointer name in Qt5Compat.


> Another thing to discuss is whether we should use raw pointers in the
> API at all or not. There are a few options again:
> 
> 1) Yes
> 
> 2) No. Use “modern” approaches instead (pass mandatory dependencies by
> either reference or const reference when using smart pointers makes no
> sense, use something optional-like or tuples to return extra data from
> functions, and so on)
> 
> 3) Mix 1 and 2.
> 
> There are pros and cons for all options. Share your opinion once again,
> please.

2) is impossible as stated, if you want to keep any amount of source 
compatibility.

Many more examples are needed, to discuss each case and eventually grasp 
some "rules".

My 2 c,
-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200131/60332a7e/attachment-0001.bin>