[Development] QtCoap: QNAM-like API or not

[Konstantin Tokarev]

18.01.2018, 12:58, "Adrien LERAVAT" <aleravat at witekio.com>:
>>  From: Konstantin Tokarev [mailto:annulen at yandex.ru]
>>  Sent: Thursday, January 18, 2018 10:42 AM
>>
>>>   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.
>
> Well if not tested, it might just as well corrupt part of the heap with no further notice, so I'm not sure it is much better.

Heap corruption can be detected with lots of existing tools, e.g. ASAN. It also won't be left unnoticed until it's too late, unlike memory leaks which may suddenly pop up when amount of data increases.

Debugging out of memory conditions may be much harder.

> But the question probably boils down: should we keep QNAM API or not for QtCoAP?
>
>>>  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

-- 
Regards,
Konstantin