[Development] API review for a new QDnsResolver class

[Jeremy Lainé]

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