It is difficult to imagine that compile-time interpretation of tests is faster than compiling and running them for anything more complex. And for trivial stuff it should not matter. Not being able to do I/O is a limitation not a feature.
For one of my C projects (ca. 450 c-files), full rebuild time on my (not super fast) laptop is just below 10 seconds (incremental builds < 1s). Compiling and linking all unit tests takes a second, and running all unit tests takes 6-7 seconds. So even running the optimized code for the tests almost doubles the time for rebuilding the full project. Although I like the machine code to be tested that is actually used. (BTW: A single C++ file with templates for CUDA someone added to the project - when activated - almost doubles the build time.)
Probably yes. Macros are about equally bad than templates in my experience (although C++ people will disagree, I do not see much difference). But mostly I plan to just let the compiler specialize the functions during optimization. I haven't looked at this specific problem though.
For one, templates can be stepped through on the debugger without additional effort, offer type checking, don't execute parameters multiple times, and don't require additional parenthesis and curly braces to protect their misuse.
Debuggers can expand macros, and you can also look at the pre-processed output or even compile that (you can't the expanded form with templates). But I agree that if it becomes more complicated this is not very good. But you know, this does not matter too much to me as I will neither use complicated macros nor templates. And simple macros are just fine.
