[Development] Making QScopedPointer scoped (again)

[Olivier Goffart]

Hi,

In modern C++, one should not handle pointer directly.  This is very error 
prone.
Qt was designed before C++98 was standardized.  The parent-child memory 
management is great, but not perfect.
Using raw pointer all over the place is confusing because you never know what 
is the ownership of your pointers.
Smart pointer allow you to take ownership explicitly.

Example:
  QGraphicsView::addItem(QGraphicsItem *item)

When you call this function, who gets the ownership?  You need to go in the 
documentation to find out. And it's not easy to remember or even guess because 
even Qt is not always consistent.  

 QGraphicesView::addItem(QScopedPointer<QGraphicsItem> item)

now you know that the the ownership is taken by the view.
Or, in case of shared ownership:

  QAbstractItemView::setSelectionModel(QSharedPointer<QAbstractItemModel> itm)

And if you return a scoped pointer, it means the caller takes ownership

  QScopedPointer<QStyle> QStyleFactory::create(QString);


Each C++ library come with its own set of smart pointer. Now that C++11 is 
there I think we should align to the same semantics, that's what C++ 
developers should learn.


On Tuesday 03 September 2013 10:02:52 Stephen Kelly wrote:
> [...]
> Again, this is what std::unique_ptr is for. We should not try to turn
> QScopedPointer into an attempt at a NIH std::unique_ptr. Where people have a
> need for a std::unique_ptr, they should use it. We should not adapt
> QScopedPointer to fit the need instead.


But because we don't want to use the STL in our ABI, we can't use 
std::unique_ptr as parameter or return value of our exported functions.

So we have to duplicate, or we have to reconsider that decision not to use the 
STL.


> Adding a move contructor to QScopedPointer makes no sense, because moving
> means 'escaping the scope', which breaks the fundamental point of
> QScopedPointer. QScopedPointer is different to std::unique_ptr and should
> remain so.

I disagree.  The fact that you can exit the scope explicitly is perfectly fine.

I would even go further and add conversions operators for STL compatibility:

inline QScopePointer<T>::QScopePointer(std::unique_ptr<T> other)
inline QScopePointer<T>::operator std::unique_ptr<T>()

-- 
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org