Slightly off-topic @algernon : Why do you prefer properties (puplic class members) to inline setters/getters? The latter would make printf-style tracing of value changes (when there is no debugger available) and assert-based invariant checking applicable at no run time costs. Moreover, they allow for…

[image] Do you use the keyboard's mouse controls? Why do you prefer properties (puplic class members) to inline setters/getters? Code size, mostly. Setters/getters have a small amount of PROGMEM and SRAM cost, and while a single one is small, many settable things can have a significant impact …

A friend of mine does embedded programming of military radios. He and I are always getting into good fun arguments about encapsulation… how he, as embedded guy, hates it for “wasting valuable bytes” and is always screaming “just let me flip the bit I need to flip”… and how I, as the enterprise devel…

Thank you for moving the topic. [image] noseglasses: to inline setters/getters My query refered to inlined access methods only. The following incurs zero runtime cost when build as release version (-DNEBUG). Both the invariant check and the log message just vaporize. #include <assert.h> #i…

After a look at the Kaleidoscope core and some of the plugins, it seems that there is no consistent choice of using public properties or member access methods. Some classes/structs provide setters/getters, some not. I would opt for consistently using inline setters and getters as they cause no ru…

One to add to the list: Allows the compiler to ignore the inline request if the usage is inappropriate I’m thinking of inline virtual functions in particular here where the compiler may choose to ignore it where a virtual function call is actually required.

[image] dshields: Allows the compiler to ignore the inline request if the usage is inappropriate That’s correct. But virtual methods are out of skope as currently not used by Kaleidoscope (am I right?). There are actually additional reasons why a compiler might refuse to inline even a non-vi…

Agreed, my background isn’t embedded systems, it’s larger scale C++ systems. I was trying to think of other justifications I’ve used for setters/getters vs. public members. You’ve already mentioned my personal favourite, assertions. I frequently use these to provide pre-conditions.

[image] dshields: my background isn’t embedded systems It’s not mine, either :wink:

[image] noseglasses: But virtual methods are out of skope as currently not used by Kaleidoscope (am I right?). There are a few places where we use virtual methods, but not much. The KaleidoscopePlugin and kaleidoscope::Hardware base classes make use of them, as does the LEDMode class. I seem …

[image] algernon: There are a few places where we use virtual methods, but not much. The KaleidoscopePlugin and kaleidoscope::Hardware base classes make use of them, as does the LEDMode class. I seem to recall there being a few other places, but indeed, we are trying to minimize their use. Ob…

Why use properties instead of setters/getters?

Programming

noseglasses (Noseglasses) December 16, 2017, 6:20pm 20

Topic		Replies	Views
Kaleidoscope's implementation - possible improvements Programming	30	3016	January 6, 2018
Single-byte key addressing (for boards with fewer than 256 keys) Kaleidoscope Internals	90	5047	December 16, 2017
Function calls in keymap definition Programming	31	2082	December 31, 2017
Do accessors increase PROGMEM consumption? Programming	0	1144	December 16, 2017
FunctionalColor 2 16-color edition (development discussion) Plugins	122	6667	April 23, 2018

Why use properties instead of setters/getters?

Related topics