I appologise in advance if I discuss something you already know or if I’ve gone into too much detail.
When I write comments like this I tend to avoid assuming prior knowledge and hope that what I write will also benefit other readers.
Just to check, is this code supposed to compile? (I’m assuming not.)
I’d like to point out that usually Arduino programs use
You can write your own
main but you should be aware of what the default
main provided by Arduino does.
On the Arduboy, I think
serialEventRun is always
false and I think there is no
attach(), but I’m not sure about
If by polymorphism you mean ‘virtual functions’ then be aware that virtual functions eat up quite a bit of progmem, so they can be quite expensive on the Arduboy.
(I’d like to point out that OOP’s definition of polymorphism via inheritance is in fact only one kind of polymorphism - specifically ‘subtyping’. There’s also ‘ad hoc’ polymorphism, a.k.a. function overloading, and ‘parametric’ polymorphism. C++ supports all three kinds in one shape or form.)
It depends on whose code you’re looking at.
Personally speaking I haven’t written many fully fledged games,
but when I write Arduboy code I tend to use just as many classes as I do in desktop code.
I think most people write procedural code either:
- Because they’re beginners who don’t know much about OOP
- (I find a surprising number of people think classes are scary and/or confusing.)
- Because they think it somehow results in less code
- (Which may or may not be true depending on the structure of the code - I think in general it makes litte difference, classes and objects are cheap if you avoid virtual functions (and possibly inheritance - but the verdict is still out on that).)
- Because they find it quicker/easier for some reason?
Personally I think a lot of people avoid classes because they think “classes make the code look bigger, therefore the generated code must be bigger too”.
As someone who knows (roughly) how classes work under-the-hood,
I’d say 8 times out of 10 that’s untrue.
Merely using classes and/or OOP doesn’t automatically make your code bigger,
what matters is how you’re using them and what specific techniques/features you’re using.
The only place I know for definite that classes are more costly is when you start using
virtual functions force the creation of a vtable and that chomps up progmem, on top of which there has to be a pointer to the vtable (an extra
sizeof(void*) bytes of RAM per object) and some extra set up code to copy the vtable pointer into the object.
I suspect that inheritance might also have a cost in some situations because I remember doing a test once that implied that both the parent and child classes get their own copy of an inherited function,
but it’s been a long time since I’ve tested that and it might only be an issue for inherited functions.
Performance isn’t much of an issue, but usually passing a pointer or reference to
Arduboy2 object to a function has a memory cost.
Arduboy2 object is one case where using a global variable (or a member variable in a
Game class) is probably a good idea, purely because not having the extra function parameter saves progmem.
(This is part of the reason I tend to prefer the
Sprites class for drawing - all the functions are
static so there’s no object to pass around.)
Firstly, technically speaking a programming paradigm is a way of classifying programming languages, not a way of programming.
Assuming you mean “is there a preferred style/method of programming on the Arduboy”, I’m not sure if there is really.
Everybody uses different mixtures of techniques and features.
Generally people stick to what they’re used to using or what they prefer.
A lot of the rules that apply to desktop programming don’t apply to programming for an embedded device for various reasons.
For example there’s not enough memory to make dynamic allocation worthwhile, so all the pracises built up around dynamic allocation (e.g. using
std::move and handling rvalue references) are effectively worthless.
However, a lot of rules that apply to readability and correctness are still important (like making sure your code is const-correct, prefering templates over macros etc).
I’d also like to point out that the reality of OOP in programming languages is quite different from what purist OOP theory believes.
Programming paradigms aren’t religions that you sign up to and stick with, they’re different tools in the same toolbox and you should strive to recognise and appreciate the benefits and drawbacks of each approach.
C++ has many different features that could be classified as belonging to different paradigms, but using the features in conjunction with each other is strongly encouraged and generally results in better quality code.