On 11/09/2011 06:21 PM, Robin Burchell wrote: > On Wed, Nov 9, 2011 at 6:05 PM, Jeremy Lainé<[email protected]> wrote: >> This talk about QtConcurrent has me wondering: do we need an asynchronous >> API at all? > I really dislike synchronous APIs, even more so when they're the only > option. Reason being that most 'normal' people won't make the effort > to get it right, even when that effort is just creating a slot. I've > seen this repeatedly in code like QtContacts, as well as complaining > about things like QNAM not enabling them to make those mistakes. Now, > while I'm a consultant, and according to the usual jokes, I get paid > to fix other people's mistakes, I'd rather not create more > capabilities for people to make them. ;) >
OK, so if we only want an async API, and we can't rely on QtConcurrent, we're back to using QObject to emits signals. That leaves just two options: 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? Jeremy _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
