[Development] The future of smart pointers in Qt API

[Alberto Mardegan]

On 01/02/20 15:02, Giuseppe D'Angelo via Development wrote:
> Il 01/02/20 12:44, Alberto Mardegan ha scritto:
>> On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote:
>>> About QUniquePointer: what's the point of reinventing std::unique_ptr
>>> under a different name?
>>
>> A Qt-ish API!
> 
> Example?

A data() method :-)

>> It's not clear to me what you mean by "alias"; if you mean a subclass,
>> then I'd be against it, because there's a (very small indeed) risk that
>> in the future the STL adds some methods that might conflict with ours,
>> or would not be Qtish enough.
> 
> I mean a type alias: using QUniquePointer = std::unique_ptr;

It still bring the risk of the STL adding some weirdly named methods
(such as empty()) which we don't want to have in a Qt class.

> 1) It's still NIH;

Which is not bad per se, in absolute terms.

> 2) The probability of future C++standards  adding features that won't be
> available in the Qt counterpart is 100%;

They could be added, and the effort should be minimal (copy the code
from STL).

> 3) Explain why Qt should raise arbitrary interoperability barriers
> literally "for the sake of it";

We can easily provide static fromStdUniquePtr and toStdUniquePtr
methods, and there wouldn't be a barrier.

> 4) Please justify the teachability efforts involved in explaining all of
> the above to Qt users.

You can explain it to our users by saying that we want a consistent API,
and that while Qt is interoperable with the STL, it can be used without
it (and as an alternative to it).

Ciao,
  Alberto


-- 
http://www.mardy.it - Geek in un lingua international