14.01.2018, 20:50, "Adrien LERAVAT" <[email protected]>: > Hi all, > > Before feature freeze, we wanted to challenge the current API for the CoAP > module. > > It is currently similar to QNAM APIs: > > \code > > QCoapClient client; > > QCoapReply *reply = client.get(QUrl("1.2.3.4:5683")); > > connect(reply, &QCoapReply::finished, this, &MyClass::onFinished); > > ... > > MyClass::onFinished(QCoapReply* reply) > > { > > qWarning() << reply->readAll(); > > reply->deleteLater(); > > } > > \endcode > > With the clear drawback of explicit memory management needed by users. We made > > some tests with a container/RAII object for the reply, and it seems fine, but > before > > moving forward in this limited timeframe, we wanted to have your feedback. > > Sample below: > > \code > > QCoapClient client; > > QCoapRequest request = client.get(QUrl("1.2.3.4:5683")); > > connect(request.reply(), &QCoapReply::finished, this, &MyClass::onFinished); > > ... > > MyClass::onFinished(const QCoapRequest &request) > > { > > qWarning() << request.reply()->readAll(); > > } > \endcode > > In that case, the QCoapReply life is managed with a > QSharedPointer<QCoapReply> in the request. > > QCoapRequest does not inherit from QObject. Anyone sees a problem with this > approach?
I dislike idea of using external reference counting, making it QExplicitlySharedDataPointer would be better > > As it wasn't merged to master yet, you can access the repo from its current > submission: > > https://codereview.qt-project.org/#/c/201311/ > > Thanks, > > Adrien Leravat > > , > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
