[Development] API review for a new QDnsResolver class

[Jeremy Lainé]

On 11/04/2011 09:01 PM, Andre Somers wrote:
> 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.
>

Let's say that another shared pointer is indeed held by the resolver class, at what point 
should we let go of this shared pointer? The answer is probably "at some point after the 
finished() signal is emitted", but when exactly?


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

Yep, otherwise we're going to have some confused users!

Jeremy