On 11/04/2011 10:15 AM, André Somers wrote:
>
> The more I think about it, the more I think it is important to fix this: who
> is
> responsible for the lifetime of the QDnsReply object?
>
Why not have the same pattern as QNAM for consistency?
> This API does not make that clear. I like the pattern in itself (also in
> QNAM), but I do
> think it would be an improvement if we were to use a shared pointer to the
> reply object.
> That at least makes clear who has ownership of the object, and prevents
> memory leaks
> when people don't realize they are supposed to delete the object.
>
I'm not sure I understand how using a QSharedPointer would clarify the API, it
would lead
to code like this:
void someObject::someMethod()
{
QSharedPointer<QDnsReply> reply = someResolver->lookupService(X, Y, Z);
connect(reply.data(), SIGNAL(finished()),
this, SLOT(replyFinished()));
}
=> surprise, the reply has been deleted!
> Alternatively, perhaps a look at QFuture would help. QFuture is another way
> results that
> are not yet ready are handled in Qt, but this time it is returned as a value
> instead of
> as a pointer. It would be nice we could come up with a single approach for
> these kinds
> of things and use that all over the place...
I brought this up with Thiago on IRC, as I quite like the idea of using a
QFuture. However
apparently this is not an option as QtConcurrent is optional.
Jeremy
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
