Closed ddemidov closed 9 years ago
The code in this PR just re-reads a property each time it is accessed. I don;t think this should matter for the most user-cases, but I would be grateful if someone would actually checked this. For example, I know that performance was important for @dsharlet.
I doubt the caching you pointed out matters much, except maybe the dp_scale member, which looks like it is still cached anyways. edit: never mind, the link was to master, not the PR. I see now it computes powf(10, decimals()) on every call to float_value.
What was important to me was that the opened file handles (not the attribute value itself) be cached so that get/setattr* is fast when called repeatedly on the same small working set (of attributes). That behavior is implemented by the lru_cache and ofstream_open/ifstream_open.
Looks good, I'll merge it now.
Thanks for doing this @ddemidov!
This finishes the work started by @fdetro on transferring the C++ bindings to the auto-generation system (see #44, #45).
Some changes to the existing C++ API had to be made:
motor::run(bool=true)
method was renamed tomotor::start()
to avoid ambiguity with therun
property defined in specification. See commit message to ed83fff for more details.dc_motor::command()
method was removed, since according to the latest specification thecommand
property is write-only.The existing implementation caches property values and sets of properties in some cases (an example). The cached values may be updated on e.g. a mode change. The autogeneration system does not allow this without moving some logic into the liquid template file. The code in this PR just re-reads a property each time it is accessed. I don;t think this should matter for the most user-cases, but I would be grateful if someone would actually checked this. For example, I know that performance was important for @dsharlet.
The tests and demos provided with the C++ bindings do work with this PR. Note that I only have motors and sensors from 31313 set, so I only checked those.