[Test.cpp] Optimize size

[hsaturn]

Before being too far from AUnit,..

[bxparks]

Good attempt, but now the behavior is subtly different when mStatus == Test::kStatusUnknown, right? The current code prints nothing, but your code now prints "Test ", without a trailing newline, which I think is a bit worse. The code duplication should be inconsequential on a desktop, so the memory savings is relevant only to an 8-bit processor, and I think even there, I think the flash memory savings will amount to about 3 x (10-15) bytes, or about 30-50 bytes.

[hsaturn]

Yes ... and this is exactly why you should use enum instead of const ints. The compiler sends a warning when unused enums are not in any case.
This is exactly what I'm doing for AUnitPC (I'm gonna rename it with this name I guess).

edit: I've finished to group many unrelated const uint8_t into three enum classes

• LifeCycle
• Verbosity
• Status

You may have a look to LifeCycle and Verbosity that should apply as they are.
For Status, I've changed Test::resolve() a way you may not like.

I prefer a lot to have enum classes because compiler will report an error when one tries to mix together values that are not related.

LifeCycle : hsaturn@1fe7947
Verbosity: hsaturn@741c164
Status: hsaturn@58f0ca8

Important note : I've not regenerated the doc after each commit, instead sed -i have changed the names of the constants, ugly.

The documentation once regenerated is pretty cool with enums 👍
Constants are grouped by function instead of mixed together. Here is what I have for the Status:

Regards

[hsaturn]

By the way, doing the changes, I've found that kStatusDone in documentation does not exists. Same for kStatusSetup if I'm not wrong.

[bxparks]

enum class is probably safer, but I created AUnit before I learned about it, and I didn't have motivation to go back to this, since most (if not all) of this is internal and not exposed to the end-user except through the Failed/Passed status messages. The LifeCycle and Status variables actually started as a single variable, and only later did it occur to me that it makes more sense to split them, so there might be some residual commingling between them.

Funny thing about enum class, when I learned about it, I started using it, then I started to find them a bit annoying and unergonomic, so I found myself slowly shifting back to using just static constexpr for internal things. I don't know, I've started to write more C and Golang, and neither of them have enums, so I guess they caused a shift in my thinking process. I think it's all part of my "C++ has too much syntax and cognitive overhead" annoyance.

[bxparks]

Correction: C has enum, not enum class, but if I recall, C-enum is in the global namespace and doesn't introduce a new type, so basically the same as an int

[hsaturn]

I do agree that enum class can be boring when using operators | & etc.
But the overhead is little and once wrote, things are a lot better IMHO.
Especially when you are a 'external' dev, or when you come back after a long period.