Putting together variable names with macros in cc65

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Oziphantom
Posts: 785
Joined: Tue Feb 07, 2017 2:03 am

Re: Putting together variable names with macros in cc65

Post by Oziphantom » Mon Nov 25, 2019 2:04 am

That is the wrong version of the code, I must have hit ctrl+V not ctrl+C when I copied the final version..sorry

Code: Select all

#define WIDE2(x) L##x
#define WIDE1(x) WIDE2(x)
#define WFILE WIDE1(__FILE__)

#define DO_LOG(x,l,f) {WCHAR buffer[512]; \
	swprintf_s(buffer, 512, L"%s:%d %s", f, l, WIDE1(x)); \
	OutputDebugString(buffer); }

#define LOG_LINE(x) DO_LOG(x,__LINE__,WFILE)
It's worth noting this is not historic code and is modern code I wrote yesterday, to test to see if VS has improved its treatment of __FILE__ and __LINE__. I've not actually needed to use them in some time, VS debugger is just a lot better these days and we have better logging solutions. This is also probably why MS haven't bothered to make a built in wchar version of __FILE__. To be clear this it will not work or compile is VS 6.

You can pass variable arguments in macros they are called 'Variadic Macros' and the gnu version is detailed here https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html Note that most compilers had their own method before the standard which means depending upon your compiler your syntax and features may vary, a quick look at the CC65 code hints that it likes the __VA_ARGS__ version as per GNU though.

"I remember when we upgraded the GCC version on the PS2 it broke them, and one of the programmers eventually worked out that using variable length arguments to pass things made it work again."

The case I was referring to was on a GCC based compiler that made ELF files for the MIPS R3000A CPU architecture as used in the Sony Playstation 2. The compiler could not optimise away things that get passed as '...' because it won't know what they are at any point and hence has to look at nee resolve them in every instance. As an example of how a different compiler needed to a totally different hack to make it work. I feel the then newly minted printf optimisation features were biting us. (details here if you are unfamiliar with printf optimisation http://www.ciselant.de/projects/gcc_pri ... rintf.html )

the point of the example was, here is a macro that in this day and age where mainline massively supported compilers still do something fairly trivial differently, which ties into my point of __LINE__ and __FILE__, i.e standard be damned, things that should work will not work and will fail in lots of different ways. Adding ## to things puts you on shaky ground, multiple ## adds to it, then define and undefing something that is used in macro and not passed into the macro as a parameter as per your original version, is really pushing it. Moreover on a compiler that is not mainline, and was made by a few people as a side project that no longer work on it.

BUT it works, and you are happy with it, so carry on.

Post Reply