Should I use QScopedPointer or std :: unique_ptr?

I am starting a new project using Qt5 and QMAKE_CXXFLAGS += -std=c++1y . I'm not sure if I should prefer QScopedPointer or std::unique_ptr .

I read somewhere that QScopedPointer is not so cool anymore.

Are there any QScopedPointer functions in unique_ptr ? Are there unique_ptr functions that I would not want when replacing QScopedPointer ? Or vice versa?

+5
source share
3 answers

QScopedPointer strictly weaker than unique_ptr because it does not support move semantics.

Its functionality is otherwise very similar.

Moving semantics is extremely useful, and accidentally using them incorrectly is extremely rare for problems. Therefore, they are very harmless (more commonly) useful.

The only reason you should use QScopedPointer is compatibility with existing code bases; and even there, considering how similar they are, the adapter would be pretty light.

So, if you do not need to adapt, use unique_ptr .


Now I will discuss adaptation.

The tricky part is the second parameter of QScopedPointer . This very roughly corresponds to the second parameter unique_ptr .

unique_ptr allows remote states. In QScopedPointer this is not the case.

 static void cleanup(T* pointer) 

corresponds to

 void operator()(T* pointer)const 

in unique_ptr in a fairly straightforward manner. So:

 template<class QDelete> struct std_deleter { template<class T> void operator()(T* target) const { QDelete::cleanup(target); } }; 

maps the Qt-deleter to the std-deleter. Another method is limited to the fact that the plaintiff does not have citizenship:

 template<class Std_deleter> struct Qt_deleter { template<class T> static void cleanup(T* target) { static_assert(std::is_empty<Std_deleter>{}, "Only works with stateless deleters"); Std_deleter{}(target); } }; 

now we can convert:

 template<class T, class D> QScopedPointer<T, Qt_deleter<D>> to_qt( std::unique_ptr<T, D>&& src ) { return src.release(); } template<class T, class D> QScopedPointer<T, Qt_deleter<D>> to_qt( std::unique_ptr<T[], D>&& src ) { return src.release(); } template<class T> QScopedPointer<T> to_qt( std::unique_ptr<T>&& src ) { return src.release(); } template<class T> QScopedPointer<T, QScopedPointerArrayDeleter> to_qt( std::unique_ptr<T[]>&& src ) { return src.release(); } template< class T, class D, class R=std::unique_ptr<T, std_deleter<D> > > to_std( QScopedPointer<T, D>&& src ) { return R(src.take()); // must be explicit } template<class T, class R=std::unique_ptr<T>> to_std( QScopedPointer<T>&& src ) { return R(src.take()); // must be explicit } template<class T, class R=std::unique_ptr<T[]>> to_std( QScopedPointer<T,QScopedPointerArrayDeleter >&& src ) { return R(src.take()); // must be explicit } 

which covers the only reason you would use QScopedPointer . There are several angular cases - the default QScopedPointer QScopedPointer must be converted to the default std::unique_ptr and vice versa.

Deleting a QScopedPointer array must be converted to unique_ptr<T[]> and vice versa.

In other cases, I just complete the uninstall process. Theoretically, a really bizarre trick was to notice that the incoming div was already wrapped and canceled the wrapping, but if your code does a lot of round trips, then probably something is wrong.

+5
source

Why are you using something not from the standard library compared to something from the standard library?

For me, there is only one reason why any good programmer could do this: if an external library provides what the standard library does not provide. Is that the case?

Consider your mobility and software updates in the future, and then make this decision.

+1
source

Although the basic intent of both classes is similar, one important difference between the two is important, which forces you to make some kind of business decision.

QScopedPointer does not have an assignment operator. Where as std :: unique_ptr there is an assignment operator.

If you want to be strict in your QT object / management and do not want the assignment to be done using QScopedPointer.

0
source

Source: https://habr.com/ru/post/1259051/


All Articles