[pjmlp]

A C in disguise with better strong typing, compile time programming that beats hands down the preprocessor, while having the preprocessor available if one insists in using it, being able to design abstractions with bounds checking, namespaces instead of 1960's prefixes,....

[sixfiveotwo]

Template specialization means more generated code, which, again, must fit in 2kb.

On very old archs (16bits, 8bits), there was no OO, because the code could not be complex enough to warrant it. It could not be complex because there wasn't room enough.

That being said, there are templated libraries (like fmt...) which may result in zero overhead in code size, so if the thread OP is using C++, then surely he could also use that library...

[ender341341]

> Template specialization means more generated code, which, again, must fit in 2kb.

modern compilers are way better about de-duplicating "different types but same instruction" template specializations so it's less of an issue than you may expect , especially if you're coming with template specialization generation from the mid/late 2000's.

[pjmlp]

No different from copy-paste hard to debug preprocessor code.

[sixfiveotwo]

This is not my claim.

[pjmlp]

It actually is, as it is voiced in a way as if preprocessor was better than using templates.

[sixfiveotwo]

You'll have to quote me, I don't see where I am implying that.

But anyway, the point that I am refuting is the use of C++ to write programs for such an extremely constrained runtime environnement, and at the same time refuse to use this library (which is template based afaik).

[pjmlp]

"Template specialization means more generated code, which, again, must fit in 2kb."

Have fun,

"Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17"

https://youtu.be/zBkNBP00wJE?si=im0ga3rW08mR8g8f