[sgtnoodle]

In embedded systems, often times not all memory is equal. Pre-computing a lookup table at runtime may not be practical due to the limited amount of RAM vs. flash memory. A constexpr or template meta program is, as you touched on, a nice way to do calculations at compile time in the existing language without having to add an explicit autocoding build step. An explicit build step eventually makes sense for sufficiently complex algorithms, but it can be a lot of build system maintenance overhead for small to medium complexity stuff. Implementing esoteric code using obscure syntax may be bad for readability, but keeping it "in the language" has a benefit of limiting the amount of project specific knowledge required to understand it.

[jstimpfle]

Now this I call a reasonable comment! I learned something, thank you.

[sgtnoodle]

Thanks! Thinking a bit more about it, I could imagine some performance impacts even on full featured CPUs. With virtual memory and the OS paging stuff in and out of physical RAM under memory pressure, read only data can be swapped out faster than writable data. The former, being immutable, can just be forgotten and then reloaded from disk when it's accessed again, while the latter has to be written to a swap file first, and writes are typically orders of magnitude slower than reads. Doesn't matter as long as you have plenty of RAM though.

[jstimpfle]

Another benefit on that line is that read-only memory can be shared between processes.

I'm not sure that this is hugely relevant these days for small stuff, though. Like < 1MB... how many instances of the same program do we have running simultaneously, anyway?.