6 ms·

This seems to more or less do what Qt's deleteLater()[1] does. [1] http://doc.qt.io/qt-5/qobject.html#deleteLater http://doc.qt.io/qt-5/qobject.html#deleteLate

This seems to more or less do what Qt's deleteLater()[1] does. [1] http://doc.qt.io/qt-5/qobject.html#deleteLater http://doc.qt.io/qt-5/qobject.html#deleteLater

astrange 10y ago
That's been in Cocoa as "autorelease" since 1994. Comes free with memory pools too.
blub 10y ago
It doesn't seem so to me. AFAIK deleteLater and autorelease pools are a way of postponing cleanup until sometime after execution returns to the message loop. That's not useable for implementing something like a graph class.
- mpweiher 10y ago
  Don't know about deleteLater, but autorelease is simply scoped to the enclosing autorelease pool. So @autorelease { [NSMutableArray array]; } ---> the array disappears here More precisely, the array gets an additional release at that point, so if someone else has retained it, it will stick around. The part about the message-loop is also true: by default, the AppKit creates a pool when it runs the message loop -messageLoop { @autorelease { handle one iteration of the loop } } So that's the default behaviour you get if you don't do anything else, but you can go as fine in terms of granularity as you want (and the overhead of doing that is pretty minimal and has gotten less with time).
- mhogomchungu 10y ago
  > That's not useable for implementing something like a graph class. How about Qt's management of QObjects through QObject's parent/child relationship?[1] [1] http://doc.qt.io/qt-4.8/objecttrees.html http://doc.qt.io/qt-4.8/objecttrees.html
  - blub 10y ago
    That's perfect for trees :)
lultimouomo 10y ago
Not really, deleteLater() will simply delete a QObject at the end of the event loop - and since QObjects have an integrated for of unique_ptr, it will delete its whole object graph with it. deferred_ptr is more of a memory region together with a form of integrated GC - it will collect unused object (even if they're part of object cycles) and destroy them when you run collect(). With QObject, you need to call deleteLater() to get rid of each object, and the "later" part only guarantees you that you won't have crashes if the object is still involved in slot calls. With deferred_ptr, you only call collect() on the deferred_heap when it suits you, and it will take care of deleting unused objects.

This seems to more or less do what Qt's deleteLater()[1] does. [1] http://doc.qt.io/qt-5/qobject.html#deleteLater http://doc.qt.io/qt-5/qobject.html#deleteLater

astrange 10y ago

That's been in Cocoa as "autorelease" since 1994. Comes free with memory pools too.

blub 10y ago

It doesn't seem so to me. AFAIK deleteLater and autorelease pools are a way of postponing cleanup until sometime after execution returns to the message loop. That's not useable for implementing something like a graph class.

mpweiher 10y ago
Don't know about deleteLater, but autorelease is simply scoped to the enclosing autorelease pool. So @autorelease { [NSMutableArray array]; } ---> the array disappears here More precisely, the array gets an additional release at that point, so if someone else has retained it, it will stick around. The part about the message-loop is also true: by default, the AppKit creates a pool when it runs the message loop -messageLoop { @autorelease { handle one iteration of the loop } } So that's the default behaviour you get if you don't do anything else, but you can go as fine in terms of granularity as you want (and the overhead of doing that is pretty minimal and has gotten less with time).
mhogomchungu 10y ago
> That's not useable for implementing something like a graph class. How about Qt's management of QObjects through QObject's parent/child relationship?[1] [1] http://doc.qt.io/qt-4.8/objecttrees.html http://doc.qt.io/qt-4.8/objecttrees.html
- blub 10y ago
  That's perfect for trees :)

lultimouomo 10y ago

Not really, deleteLater() will simply delete a QObject at the end of the event loop - and since QObjects have an integrated for of unique_ptr, it will delete its whole object graph with it. deferred_ptr is more of a memory region together with a form of integrated GC - it will collect unused object (even if they're part of object cycles) and destroy them when you run collect(). With QObject, you need to call deleteLater() to get rid of each object, and the "later" part only guarantees you that you won't have crashes if the object is still involved in slot calls. With deferred_ptr, you only call collect() on the deferred_heap when it suits you, and it will take care of deleting unused objects.