[Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

> Not using smart pointers in our API (neither the Qt's or the std:: ones)
> allows each developer to use his own preferred solution with a minimal
> effort. People might want to use boost smart pointers, SaferCPlusCplus,
> or even their own handcrafted smart pointer templates. I don't think
> that Qt should make a choice for them.
The huge integration problem is that it's not always clear which object 
handles lifetime of which object and when ownership is transferred. It 
makes a process of integration with smart pointers painful and hardly 
possible.

For example what can you tell about object's lifetime if you see a code 
like this:

Foo *someAPI();

or

someAPI(Foo *ptr);

Usually, not too much. You need to either read a documentation or an 
implementation. This is also not that easy to catch a moment when object 
is deleted.

But if you see API like this:

std::unique_ptr<Foo> someAPI();

You have much more information about managed object just by reading the 
code. This is also much easier to understand what can or cannot be done 
with the returned value in the example above.

There also were good arguments about exceptions. We shouldn't forget 
that Qt can be used with a program that uses exceptions.

On 2/4/20 12:24 PM, Alberto Mardegan wrote:
> Going back to the original question again, as I'm not sure I agree with
> this claim:
>
> On 31/01/20 13:07, Vitaly Fanaskov wrote:
>> 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.
> I ran a quick grep over QtBase's source code, and indeed it looks like
> QSharedPointer and QScopedPointer are not used in the public API. But is
> this bad?
>
> Just imagine if we had been spreading Q{Shared,Scoped}Pointer all over
> Qt's API in Qt4 times: we probably would not even be having this
> conversation now, as switching from the Qt pointer classes to the std::
> ones might have been way too problematic.
>
> So, if, from this perspective, it's good that Qt has not embraced (Qt)
> smart pointers before, I'm tempted to draw the conclusion that it would
> be a wise idea to continue avoiding embracing a specific smart pointer
> implementation.
>
> Not using smart pointers in our API (neither the Qt's or the std:: ones)
> allows each developer to use his own preferred solution with a minimal
> effort. People might want to use boost smart pointers, SaferCPlusCplus,
> or even their own handcrafted smart pointer templates. I don't think
> that Qt should make a choice for them.
>
> Ciao,
>    Alberto
>
>
-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team