Kaleidoscope's implementation - possible improvements

[noseglasses]

@merlin

Don’t setters and getters require copy operations that can sometimes be skipped with direct access, even if the code is inlined?

Inlined setters and getter can be optimized by the compiler in a sense that they virtually disappear.

[noseglasses]

@merlin

And even then, backwards compatibility can be maintained by (ab)using operator overloading and typecasting tricks.

That sounds like believing in miracles. There are no such tricks that can repair that.

[noseglasses]

Moreover, its a bad design when one already has to think about repairing before having startet.

In C++ getters and setters are very useful.

[noseglasses]

See also

Why use properties instead of setters/getters?

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 value clamping and change notifications/hooks, if needed. Setters and getters are easy to define via macros without degrading readability, as e.g. done in the vtk project.

[merlin (Michael Richters)]

@noseglasses

In C++ getters and setters are very useful.

Yes, they are. But if we have an object of any kind (class, struct, or union) that does contain a public data member for whatever reason the author chose to do so, I find it useful to omit the trailing underscore.

And see also @algernon’s response:

Why use properties instead of 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 on code size. If I recall correctly, we’re talking about over a hundred bytes saved by using public properiets instead of accessors. While accessors have a lot of uses, and I’d prefer them on code that runs on less constrained hardware, when resources are as limited as they are on the AVRs used in the Model01, practicality wins ove…

Feel free to complicate your code with impenetrable C++ -isms all you like, but your solutions to the problems posed by slavish adherence to strict object-oriented coding practices make it even more difficult for people like me to meaningfully contribute to the project. When you claim that it doesn’t degrade readability, that’s a subjective judgement, not shared by everyone.

[rumpel]

@merlin

Feel free to complicate your code with impenetrable C++ -isms all you like, but your solutions to the problems posed by slavish adherence to strict object-oriented coding practices make it even more difficult for people like me to meaningfully contribute to the project.

Wait a minute. This is C++ we are talking about. It is an object-oriented programming language, and those coding practices exist for a reason. If you come from a C background and have difficulty understanding the concepts of C++, that’s on you.

When you claim that it doesn’t degrade readability, that’s a subjective judgement, not shared by everyone.

Using setters/getters is common practice. Some would even go so far as to say they improve readablitiy.

However, the code size argument does have merit.

By the way, there is a different argument against using getters/setters in object-oriented languages, but that would stir the disscussion in an entirely different direction. It’s also never taught by programming books.

[noseglasses]

@rumpel

However, the code size argument does have merit.

But it is wrong. Inlined accessors are optimized out. You won’t see them in assembly, neither in PROGMEM. Those who doubt that may try themselves.

[merlin (Michael Richters)]

@rumpel

Wait a minute. This is C++ we are talking about. It is an object-oriented programming language, and those coding practices exist for a reason. If you come from a C background and have difficulty understanding the concepts of C++, that’s on you.

The problem is that we have no choice. If we have code that makes more sense as a procedural program, we can’t use some other language on Arduino; we’re stuck with C++. That doesn’t mean that we have to suck it up and write object-oriented code with objects that don’t make sense; C++ still allows us to write procedural code. Insisting on OOP conventions and best practices, even if the code is fundamentally procedural is not a good idea.

[noseglasses]

@merlin

fundamentally procedural

What is fundamentally procedual. Never heard off.

[noseglasses]

@noseglasses

Inlined setters and getter can be optimized by the compiler in a sense that they virtually disappear.

See also

Do accessors increase PROGMEM consumption?

There were discussions about the benefits of accessor functions [1], [2], [3]. Apart from religious aspects of the discussion, the statement that accessors cause runtime costs appeared quite often. This is something that is hard to get out of the heads of programmers coming from other languages that do not feature function inlining, C programmers included. But C++ has its own rules. Inline functions can actually disappear from the assembly and thus from our precious PROGMEM. C++'s inline keywo…

[AmigoNico (Nicholas Sterling)]

With regard to the use of C++ features, there is one advantage to sticking with C. Without starting a flame war, there are some big potential advantages to converting to Rust someday. There are a number of programs out there that will convert C to Rust automatically, but I think C++ is more problematic.

I’m sure memory safety and code readability come to mind as advantages, but it is probably less well known that at some point Rust code should perform better than C code. It’s about a wash now, but Rust is for now just using the C optimizer, which does not know about Rust semantics which enable additional optimizations. Eventually a more capable optimizer will land, and existing Rust code will just get optimized better.

Something to think about down the road, but I just wanted to point out that such a move might be easier if the code is plain C.

Caveat: I’m sure there are folks here who know more about Rust than I do.