Kaleidoscope's implementation - possible improvements

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

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

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

In C++ getters and setters are very useful.

See also

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:

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.

2 Likes

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.

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.

1 Like

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.

What is fundamentally procedual. Never heard off.

See also

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.

4 Likes