On 11/09/2011 07:21 PM, Peter Hartmann wrote: > On 11/09/2011 06:43 PM, ext Jeremy Lainé wrote: >> (...) >> A/ static QDnsReply* QDnsReply::lookup(QDnsReply::Type, QString); >> >> pro: easy to connect to the QDnsReply's signal >> con: it's entirely up to the user to handle deletion. Judging by your >> comments above, I >> doubt you favor it? >> >> or >> >> B/ static QSharedPointer<QDnsReply> QDnsReply::lookup(QDnsReply::Type, >> QString); >> >> pro: memory ownership is explicit >> con: how used are our users to manipulating QSharedPointer with respect to >> signals and >> such? > > I rather favour option B (lessons learned from QNAM), because I think option > A might > lead to undeleted replies, which is what we experienced in the case of > QNetworkReply *QNetworkAccessmanager::get(...). >
OK, there is always another option: C/ you make QDnsReply's constructor public, and let the user manage the lifetime of the object. This is what the Q3Dns API looks like. What I don't like about Q3Dns's API is that it's unclear when the request is actually made. Jeremy _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
