[Development] API review for a new QDnsResolver class

[Andre Somers]

Op 4-11-2011 20:31, Jeremy Lainé schreef:
> 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?
How about fixing QNAM to solve this issue there as well then?
>
>> 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!
Has it? Probably not, as the lookup service is still holding on to 
another shared pointer to it in order to know where to put the results 
of the lookup, right? Using a shared pointer, at least you are sure the 
object is valid while either the receiver or the resolver is still 
interested in having the object around, and as soon as that is no longer 
the case, it will be properly deleted. Using raw pointers, you can not 
be sure of either.

<dreaming>
Would be nice by the way if connect could directly deal with QObjects in 
shared pointers...
</dreaming>

>
>> 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.
Me too. My point was, that we have slightly different patters for 
basically the same sort of thing in different places in Qt. QFuture is 
_currently_ coupled with QtConcurrent, but is there a strong reason why 
is must be? I was not privy to that IRC chat, perhaps you could tell us 
the reasoning why it would not be possible?

I think the Qt API would benefit from having the same kind of pattern 
for waiting for asynchronous results, whether from calculation or from 
the network or from some other resource. However, at all times, I think 
it must be clear who owns what object, and who is responsible for 
cleaning it up.

André