Hi,

Pure from a transitioning perspective: isn't it rather late for such a massive change? Wasn't it the idea that 5.15 would be the "transitioning" version that people could use to make their code Qt6-ready? In that case, should this not have already been implemented in Qt 5.15, as I think that one is FF now?

Cheers,

André

On 31-01-20 11:07, Vitaly Fanaskov wrote:
Hello everyone,

We’ve been discussing for a while how Qt6 API can be improved with using
smart pointers. Recently we came into some conclusions and want to
discuss them with the community.

Smart pointers are for sure much better to use than raw pointers for
many reasons. They manage lifetime automatically, show ownership
semantic, and make code safer. It’s planned to officially recommend them
to use in Qt6 API instead of raw pointers whenever this is possible. For
sure, it should only be a choice for newly designed API.

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.

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.

If there are any related things to discuss, let’s do that in this thread.

_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to