[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: GLib/GObject+C as the lingua franca?
From:       Kevin Krammer <kevin.krammer () gmx ! at>
Date:       2008-07-30 17:06:42
Message-ID: 200807301906.47870.kevin.krammer () gmx ! at
[Download RAW message or body]


On Wednesday 30 July 2008, nf2 wrote:
> Kevin Krammer wrote:

> > Probably more like a QFileInfo
>
> Perhaps also a bit like KUrl, but with methods to start various file
> operations.

Right.
Though the functions to create operations on it might also be better somewhere 
else, e.g. in a namespace like KIO's operations.

> > Which would put all the data related operations into a QFile/QIODevice
> > like class which does not need to be copied.
> >
> > As for the stream: if you really need that in your top level API, signals
> > should be OK but you can of course also use a call back interface.
> > I don't think there will be any use case where you need to copy a stream
> > object, so inheriting from QObject should be no problem.
>
> It's quite tricky. Have a look at my "readfileasync" example:
>
> http://websvn.kde.org/trunk/playground/libs/kommodity/samples/kgio-readfile
>async-sample.h
> http://websvn.kde.org/trunk/playground/libs/kommodity/samples/kgio-readfile
>async-sample.cpp
>
> The first async operation read() (Actually it's an "open") is started
> from File (i have split off the async operations from File to
> FileasyncOperation, but that doesn't matter).
>
>      m_fileAsyncOperation = FileAsyncOperation(file);
>      connect(&m_fileAsyncOperation, SIGNAL(inputStreamReady(*const* File&,
> *const* FileInputStream &, *const* Error &)), *this*,
> SLOT(inputStreamReady(*const* File&, *const* FileInputStream &, *const*
> Error &)));
>
>      m_fileAsyncOperation.read();

Hmm,
A couple of comments:
1) why does the signal transport a file? Is it not also accessible through the 
stream?

2) If the stream object is intended to be kept after the slot ends, it should 
perhaps be a pointer

3) error in a "ready" signal looks very wrong

> On sucess a FileInputStream will be returned by the signal. Then i
> connect signals to the inputstream and start reading.  The problem is
> that here i'm saving the FileInputStream to a member variable of my
> application object. Perhaps it's not necessary to keep a reference to
> the FileInputStream - Hmm...

It seems the stream's signals also transport the stream itself, so probably 
not. Depends on whether you need to call stream methods outside signals 
connected to it.

> If FileInputStream wasn't a copyable explicitly sharing wrapper this
> would be difficult. Storing the pointer somewhere else doesn't increment
> the reference count.

You could probably use a boost shared_ptr or something similar if you really 
need a "value" object, though using a real pointer should work as well, since 
its lifetime currently seems to be controlled by the FileAsyncOperation 
object (it emit a reference so it stays the owner of whatever pointer it uses 
internally if it uses one at all)

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]