[Development] unique_ptr and Qt, Take 2

[Vitaly Fanaskov]

Well, it should be possible, to support parents, created on the stack. We already have the code to do it. The code is private, unfortunately, but it doesn't matter. In the following file:

qtbase/src/corelib/tools/qsharedpointer_impl.h

We have the following constructor, used by QPointer:

template <class X> inline QWeakPointer(X *ptr, bool) : d(ptr ? Data::getAndRef(ptr) : nullptr), value(ptr) { }

That's it. We can use it for both case. There are some changes in QObject interface:

QObject(QWeakPointer<QObject> parent = {})

// Use casting operator instead?

QWeakPointer<QObject> asWeakRef() { return {this, true}; } QWeakPointer<const QObject> asWeakRef() const { return {this, true}; } QWeakPointer<QObject> parent;

And some usage examples:

     auto o1 = QSharedPointer<QObject>(new QObject);

auto o2 = new QObject(o1);

// Or...



QObject o1;

QObject o2(o1.asWeakRef());

I compiled and tested after patching Qt, works fine. Of course, I didn't implement full functionality, just a shallow example. QWeakPointer also gracefully handles the case if a user tries to invoke something like toStrongRef() in the second example. Some reasonable warning will be put to the terminal and an empty QSharedPointer returned.

This also means that we will have to use our own smart pointers everywhere in the interface (for consistency). We will also have to change some things (e.g., make QScopePointer movable), but this is the matter of another discussion. Which is not bad, because it'll help to avoid some well-known problems of using std::* in library interfaces, along with memory allocation/cleaning issues. And again, this is much better than having raw pointers.

On 5/6/19 12:04 PM, Lars Knoll wrote:

On 6 May 2019, at 10:27, Konstantin Shegunov <kshegunov at gmail.com<mailto:kshegunov at gmail.com>> wrote:

On Mon, May 6, 2019 at 10:42 AM Lars Knoll <lars.knoll at qt.io<mailto:lars.knoll at qt.io>> wrote:
Not sure whether it’s most projects, but there certainly are users doing it. And we’ve been using the pattern in our examples in some cases as well. But I can relate to Allan that creating widgets on the stack is bad style (as it conflicts with the way we memory manage them), and if I’d have a choice today, I would probably prefer to enforce them to be created on the heap by some means.

Fine, there seems to be somewhat of an argument in that regard. I'd raise the question then, what should be done for QObject derived classes, and I don't mean the ones that come from Qt (i.e. QFile, which Thiago mentioned), but the ones the user defines. In the end QObject is for us to derive from - get signals and slots and all those goodies. But then if one restricts QObject to be on the heap how do we treat the user classes? What I mean is - you can control how allocations happen in the library, say you provide custom new/delete for QObject and/or QWidget and restrict the stack (presumably through some trickery that disables the constructor), does this mean we are to force the user to write their own allocation operators for their classes? This doesn't really sound practical to say the least. Moreover there's really little reason (from the user's point of view) to have something in the heap if it can go on the stack. What do we do with QCoreApplicaiton, force the heap on it?

It’s somewhat of a philosophical discussion now, as we are where we are and users can and are creating QObject’s on the stack. I don’t think we can change that now (even for Qt 6), and restricting it would lead to rather ugly syntax in C++ (as the language doesn’t really help enforcing something like this). So that means we’ll have to continue to support it.

Cheers,
Lars




_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development


--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190506/1535a9ed/attachment.html>