-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C Plugins interface is not robust #861
Comments
This is even more blocking for classes which are intended to be derived like |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are coding caveats in plugin interfaces. Coding rules should be automatically checked to avoid issues.
For example:
Datapoint
) do not define their destructor asvirtual
. Thus it is impossible to define a sub-class because destructor will never be called, implying memory leaks (and inconsistent behavior)typedef void (*INGEST_CB)(void *, Reading);
=> Why is that passed by copy?. The documentation does not provide the actual definition ofINGEST_CB
(in https://fledge-iot.readthedocs.io/en/develop/plugin_developers_guide/03_south_C_plugins.html) This seems like a critical point because Readings copy imply a deep copy of Datapoints which may contain deep vectors of vectors of vectors ... Moreover there are a lot of useless copies of readings all during processing lifetime, thus leading to unefficient code executionThis is important to be able to derive clases, typically in scope of unit tests (For example I want to use a memory leak checker for datapoints in my unit tests:
Reading
).The text was updated successfully, but these errors were encountered: