Re: XQuartz internal-behind-the-scenes question
Re: XQuartz internal-behind-the-scenes question
- Subject: Re: XQuartz internal-behind-the-scenes question
- From: René J.V. Bertin <email@hidden>
- Date: Mon, 15 Sep 2014 20:13:30 +0200
On Monday September 15 2014 10:32:03 Jeremy Huddleston Sequoia wrote:
> > I'd have thought so, for X11 apps ... but here the crashing apps aren't. We're talking about KDevelop, btw.
>
> Can you point us to the crash log or bug report in question?
Sure: https://bugs.kde.org/show_bug.cgi?id=338829
Lots of discussion and more links: https://git.reviewboard.kde.org/r/120150/
> If deleteLater is really an autorelease, then it is extremely poorly named. deleteLater gives the impression that the memory will be freed at a later point (what is the guarantee that someone else won't be using it?). autorelease means that one of the references will be released at a later point (someone else could still have a reference, and that would be ok).
Ah, yes, in that sense it's different. The basic QObject::deleteLater just calls QCoreApplication::postEvent(this, new QEvent(QEvent::DeferredDelete));
and I presume that doesn't do reference counting. If the object is still in use outside of the frame in which deleteLater defers the delete, you're just as cooked as when someone does one release too many in ObjC ...
> but for the most part, you shouldn't need to worry about autorelease pools as the run loop sets one up for you.
Yes, that's true when you're working in a a context where ObjC is the underlying basis (does that make sense?). When you're working on a framework that has to work on multiple platforms and you just need ObjC because you have to on OS X, you'll probably find yourself without that event loop ...
> You should autorelease objects when you are done with them and passing them to someone else.
> You should release objects when you are done with them and not passing them to someone else.
It sounds so easy. Just like some math teachers can make the most complex things sound like a piece of cake. Until you have to do it yourself ;)
> Yes, but QT could. Heck, we have retain/release for various libSystem objects in OS X, and that's in C. retain/release is not a language concept, it's an API contract.
Yes, but I think you'll agree that they probably should have started out with that, and somehow enforced using it (raising an exception every time someone calls a dtor with a non-zero reference count?) and that it's neigh impossible to start imposing such a contract now. I haven't looked it up, but I have a hunch Qt didn't "come to OS X" at their version 1.0 ...
> That's the same in C++ as it is in ObjC. Once you're in the destructor (dealloc), your memory is getting reclaimed.
I know that. But you're rarely supposed to call dealloc (unless in a child's dealloc), no?
> No, ObjC and C++ are no different in that regard. It's just that the ObjC runtime pushes retain/release. A C++ runtime or high level framework (like QT) could easily add retain/release to their base class and an assert in their base class's destructor to enforce proper usage.
Oh, I hadn't read that when I said basically the same thing. They could. But I don't want to be there (nor them) if ever they make the decision to do so. Maybe not even if they offer to contract me to do the changes for all their paying clients ... The code base using Qt is not just huge, after all.
(BTW, one is supposed to write 'Qt' and pronounce 'Cute' ... I don't know if that's to avoid confusion with QT as in QuickTime...)
René
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden