GLib/GObject+C as the lingua franca?
kevin.krammer at gmx.at
Wed Jul 30 18:06:42 BST 2008
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
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:
> 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 &)));
A couple of comments:
1) why does the signal transport a file? Is it not also accessible through the
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)
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel