These solutions are what is presented at the beginning of the article, basically. They suffer from a maintenance and readability issue (most editors will disable syntax in the macro scope, you have to mess with the '\', ...).
In this particular case it's not exactly a problem, but when you reach a 100+ lines macro, it becomes one.
It's a bit like maintaining pixel shaders in strings, it pretty quickly becomes a huge PITA.
Now if you read carefully the post, you will notice that I'm not encouraging the latest multiple files method, it is just presented because it's a common pattern and has its use cases.
I think what is described in "Mixing full functions mechanism and macros" would be more appropriate for the example you picked. Again, you have to assume that the function is going to grow, and it needs to be editable.
Yes, that's what I presented. Sometimes though you need a function because you have a function pointer tab for each feature (foo, bar, baz), that's why I wrapped them to show the mechanism of inlining.
I prefer the single file solution too. I suppose it comes down to how much having escape markers on every line of the function implementation bothers you, and if your favorite code editor does full syntax highlighting in such a case.
Yes, but that is now a worker function that handles every if(n == x) case explicitly in the body, not something you need the preprocessor for anymore. Nothing against it, but it is a different design.
I see. I was thinking in the context of your second pastebin link and the evil_template.c snippet in the article, where the functions are actually generic (and in which case you can't avoid the function being declared as a macro unless you go the multiple-includes route).
http://pastebin.com/uWSs7ca7
We can improve the macro further by removing the unnecessary if statement and the index number:
http://pastebin.com/vPTTYPpe