> From: Konstantin Tokarev [mailto:[email protected]] > 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. 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
