ev3dev / ev3dev-lang

(deprecated) language bindings for ev3dev sensors, motors, LEDs, etc.
GNU General Public License v2.0
56 stars 39 forks source link

[cpp] Transfer the C++ bindings to the auto-generation system #47

Closed ddemidov closed 9 years ago

ddemidov commented 9 years ago

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:

  1. motor::run(bool=true) method was renamed to motor::start() to avoid ambiguity with the run property defined in specification. See commit message to ed83fff for more details.
  2. dc_motor::command() method was removed, since according to the latest specification the command 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.

dsharlet commented 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.

WasabiFan commented 9 years ago

Looks good, I'll merge it now.

Thanks for doing this @ddemidov!