[Development] The future of smart pointers in Qt API

[Alberto Mardegan]

On 01/02/20 15:32, Giuseppe D'Angelo via Development wrote:
> Il 01/02/20 12:37, Alberto Mardegan ha scritto:
>> Do we need to have such a counterpart? In my work experience, when I'm
>> not allowed to use Qt and am restricted to the STL, all the times I had
>> to use std::unique_ptr was to get the same behaviour as a QScopedPointer.
> 
> So you never had to pass one to a function, return one from a function,
> create a vector of them? Color me *very* suspicious.

Believe it or not :-) I find std::shared_ptr easier to use when passing
pointers to and from functions. And I never needed to put them into an
array.

> The same subset is available in the Standard Library. The type you're
> looking for is "const std::unique_ptr".

Sure, I'm just saying that "QScopedPointer" is more descriptive.

>> So, I don't really care about std::unique_ptr, but I like Vitaly's
>> suggestion of having a QUniquePointer with a nice data() method.
> 
> How about working with upstream and convincing them that having data()
> (in addition to get()) on smart pointers is a good idea? Is having
> data() the _only_ argument here?

The STL could still add a method made up of two words in the future, and
it's unlikely that they'll use camelCase (or that they'd accept a
camelCase variant).

Ciao,
  Alberto


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