[Development] QtCoap: QNAM-like API or not

Konstantin Tokarev annulen at yandex.ru
Thu Jan 18 10:37:39 CET 2018

18.01.2018, 12:35, "Adrien LERAVAT" <aleravat at witekio.com>:
> On Sunday 14 January 2018 17:49:48 Adrien LERAVAT wrote:
>>  > 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?
>>  The API sounds interesting, but it's a departure of what we are used in QNAM.
>>  What happened to the idea of using a setter on the manager, for making the replies self-delete if wanted? (it was mentioned on the > QtCS) That had the advantage that can be added to QNAM as well, so both can end up having a similar API.
> Well it can surely solve the "forgot to delete reply" case, but as a developer, if you're not aware of the change (not the one calling the setter), the new behavior change will be far from obvious. Going from "pseudo memory leak" to "dangling pointers & crashes" if they are not careful enough.

On small device crashes are more favorable outcome than "pseudo" memory leaks, because the latter lead to delayed crashes and therefore are much harder to fix.

> So it has the advantage to be applicable to QNAM, but doesn't really feel like a user-proof solution to me.
> Still it can be easily applied to QCoapClient, so if there is a consensus around it, we can go that way.
> Adrien Leravat
> Software architect, Witekio
> http://witekio.com
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


More information about the Development mailing list