smart pointers

[Nicolas Fella]

On 17/05/2022 14:34, Xaver Hugl wrote:
> Hello,
>
> I noticed that in KWin we use a lot of smart pointers and we mix Qt
> and C++ standard library ones quite a lot. Judging by a few searches
> in frameworks repositories, it's a similar mix there.
> I'd like to propose that going forwards we use C++ standard library
> smart pointers in new code and also port old code (where possible)
> away from Qt smart pointers, for the following reasons:
> - it increases consistency, making code a little bit easier to read
> - in the general  C++ community, smart pointers from the standard
> librariy are much more well known, which should make it a little bit
> easier for new contributors to settle in
> - std::unique_ptr allows to properly express ownership transfers with
> move semantics, which QScopedPointer does not support
> - std::shared_ptr is more efficient than QSharedPointer, it has half
> the overhead on reference changes
>
> What do you all think?
>
> Greetings,
> Xaver

Hi,

we recently had a similar discussion of Qt vs STL in the context of
containers. The key takeaways were:

- By default use Qt containers, especially in interfaces, for
interoperability with existing code that tends to use Qt containers

- Using STL containers is okay if there's a tangible benefit, e.g.
performance

With smart pointers the situation is a bit different, though. Almost no
Qt API takes or returns a smart pointer, so interoperability is not a
concern here. For KF5 this is not much different, with some exceptions
(KService::Ptr is a QExplicitlySharedDataPointer, some classes in
NetworkManagerQt/ModemManangerQt use QSharedPointer in their interfaces etc)

In general I'm leaning towards favoring STL smart pointers, not the
least given that even the Qt maintainers often advocate for the STL ones.

Cheers

Nico