[Development] Ref-counted quit

Thiago Macieira thiago.macieira at intel.com
Mon Jan 2 14:34:36 CET 2012


On Monday, 2 de January de 2012 14.25.17, Olivier Goffart wrote:
>  ref()  means "keep the application alive until i call deref()
> And every ref() must be paired with a deref()
> exactly like QSharedData ref.  that is i hink a concept that is very common
> and easy to understand.
> 
> After, it can be wrapped into more high level API in QtGui or something.

That is not a good reason to have *public* API. I don't have any doubts that 
internally this will be a refcounter. I'm objecting to having an ugly and 
under-defined API in QCoreApplication.

> > It sounds like the QCoreApplication object will be deleted when the count
> > reaches zero, which isn't true.
> 
> Yes, it is true.

To be clear: are you agreeing with me ("what you said is true") or are you 
disagreeing with me ("what you said isn't true actually is true") ?

> > You say I am discarding valid use-cases. Maybe I am. Please propose a
> > counter- alternative to what I have proposed. Start by not changing
> > QCoreApplication's API -- a new class would be better.
> 
> a kind of  QKeepApplicationAlive object that would call ref() in its
> constructor, and deref() in its destructor?
> Why not, but i like the simple ref/deref in QCoreApplication better.
> 
> I beleive the ref()/deref() API does the job well, and is very simple and
> easy.
> And it has to be in QtCore, so it can be used by ui-less API (such as KJob)

It's simpler to expose the data pointer in QList and let users manage pointers 
on their own. It's more efficient, since there's no man-in-the-middle.

Yet that's no good reason to expose the internal implementation details as the 
front-end API.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120102/eb47e765/attachment.sig>


More information about the Development mailing list