[Development] Qt 5.9's new garbage collector documentation? + root_ptr
Ed Leaver
ewleaver at comcast.net
Thu Jul 6 01:49:56 CEST 2017
On 07/05/2017 06:31 PM, Phil Bouchard wrote:
> On 07/05/2017 02:29 AM, Thiago Macieira wrote:
>> On Tuesday, 4 July 2017 21:03:14 PDT Phil Bouchard wrote:
>>> Hi,
>>>
>>> I read Qt 5.9 is using a new garbage collector that is more
>>> predictable.
>>> First good job and second I was wondering if there is any
>>> documentation on that garbage collector in question.
>>
>> That might be in the QML engine VM. The rest of Qt does not use garbage
>> collectors.
>>
>>> I guess if there is any interests to make the garbage collector
>>> perfectly deterministic then root_ptr could be relatively easily
>>> integrated at this stage.
>>
>> How does root_ptr work with JavaScript semantics?
>
> (So as you can see in the file attached I have revamped my Javascript
> skills. And so with the QML.)
>
> But first of all root_ptr is as you know a "set" of reference counted
> pointers, where the "set" vanished from existence when the destructor
> of the associated root_ptr is called.
>
> For example in HTML we could have 1 root_ptr for each HTML page and
> when this page is destroyed then the root_ptr guarantees all
> associated nodes will be destructed as well. When I refer to a node I
> mean the representation of an atomic variable or a function in
> Javascript which is pointed to by a reference counted pointer. So you
> can have all the mess you want in Javascript, when the page is
> destroyed then all memory associated to that page is freed.
>
> It's the same thing with QML and its windows. When a window is
> destroyed then all associated variables will vanish as well, cyclic or
> not. From my experience, the only way a window can return a value is
> either by sending a signal with its parameters passed by value or by
> storing them in some local database. But the parent shouldn't have
> any pointer connection of QML / Javascript type with its child window
> (downstream) otherwise it's bad programming. Ex.:
>
> Window 1
> ---------
> | | Window 2
> | | ---
> | root_ptr2->| |
> | | ---
> root_ptr1->| |
> | | Window 3
> | | ---
> | root_ptr3->| |
> | | ---
> ---------
>
> Here when root_ptr2 gets deleted from the list of Window 1's childs
> then everything inside Window 2 will get destroyed. The same for
> root_ptr3 / Window 3. If root_ptr1 gets destroyed then the whole app
> is guaranteed to vanish.
>
>
> Regards,
> -Phil
> https://github.com/philippeb8/root_ptr
>
It may be just a matter of semantics. What you describe is pretty much
how C++ QtWidgets work. One doesn't ordinarily think of convenient but
informed use of smart pointers to be garbage collection. One doesn't
ordinarily think of QtWidgets themselves as being particularly "smart"
pointers, either. (But they've been enough to fool me!)
C++ QObjects do support "real" smart pointers in guise of
QScopedPointer, QSharedPointer, and QWeakPointer, plus a few others. So
Qt certainly knows how to do what you describe without Java-style
garbage collection.
That's the C++ side, which I understand to underlie much of QML. I hope
Thiago can correct my own mis-perceptions, and elaborate more.
Regards,
Ed Leaver
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170705/502165a8/attachment.html>
More information about the Development
mailing list