Pokitto Magazine: C++/Programming Topic suggestions


#1

Following on from the discussions in “Pokitto magazine #2, article ideas?”,
if there were to be articles in the magazine covering programming topics*,
what sorts of things would people like to read about?

* Particularly C++ topics, but possibly also general programming topics or topics covering other languages.
Suggestions can be advanced topics, simple topics or a mixture of both.

(Knowledge is relative - that which one does not know often seems more complex than that which one does know, and that which one does know often seems simpler in hindsight.)


Pokitto Magazine Issue 2: Article Submissions
#2

These two might be interesting:

  • How to have data structured in structs/classes stored in pure ROM, and ensure they are actually stored in pure ROM
  • A few cool examples of template programming, not too obscure/abstract ones
    • Like how to replace macro with templates
    • Refactoring two game entities that share a lot of codes with only varying parameters using a single template

#3

As far as I understand any objects with static storage duration (i.e. globals) that are marked const or constexpr are automagically stored in ROM (assuming they aren’t simple enough to be turned into immediate operands for machine code instructions).

Drat, there goes my peano arithmetic example. :P

(I’m not entirely joking. I got bored one day last month and wrote this one afternoon just for a laugh.)

These are both good ideas, but specific examples would help.

E.g. Replacing min and max macros are pretty obvious cases, but examining those is mostly academic because they already exist in the standard library as std::min and std::max. There’s a lot of similar cases where the C++ standard library has you covered (e.g. std::swap, std::array, std::vector).

Points and vectors are quite a good example,
but would enough people be familiar with points and vectors to understand the example?

I suppose a grid is another potential example.

Beyond that I struggle to think of ideas, mainly because I think differently about things.
Some people write macros I wouldn’t even contemplate writing because to me macros no longer feel like a natural way to solve any problem other than conditional compilation.


#4

Constexpr instances won’t be an issue because of the various requirements. However, const instances might be moved into static RAM, depending on various things:

  • Constructors have to be simple enough (possibly constexpr ?).
  • Mutable fields are of course excluded.
  • Surprisingly, it seems polymorphic hierarchies might be an issue as well (Didn’t verify this but if true, it’s very annoying).
  • There are other too but .

(I think it’s something related to trivial constructors - but I keep forgetting the definition so I’m not sure)

Which is why I thought a complete and accurate article about this might help people about shaping properly their ROM-compatible classes when using C++. Basically small articles, pieces of information that can be useful to someone using C++ on a pokitto - or even another MCU-based device


#5

The precise definition is probably something along the line of the trivial type named requirement, or at least needs a ‘trivial’ constructor and destructor.

If you mean that monstrosity, anyone caught using that should have their programming licence revoked and then executed by firing squad. :P

That’s plausible.
Most uses of polymorphism require virtual destructors,
which would violate ‘triviality’, which is potentially a requirement for ROM-ing.

I’m not sure why you’d want to put a runtime polymorphic object in ROM anyway though,
that seems like it would potentially defeat the point.
Unless the idea is to have objects of subclasses stored in ROM and reference them through parent class pointers or references.
But if that’s the case you don’t need a virtual destructor because you’d want those objects to be trivially destructible anyway.

(Being trivially destructible is almost certainly a guarantee for something to exist in ROM - you want destruction to be a ‘nop’ so it can be optimised out completely.)

The most important part to remember is ‘not user-provided’.
(I.e. implicitly defined, implicitly defaulted or explicitly defaulted.)

This is true, but it would certainly be an advanced article (the fact we’re mentioning triviality at all is a big hint to that), and I’m not sure anyone actually knows definitively.
Unless it’s documented by mbed it might take a bit of experimentation and digging.