D
Dan Pop
In said:If one does happen to have a compiler that supports __func__, and wants to
use it while developing portable code, it shouldn't be too difficult to
wrap it up with the help of the preprocessor in order to selectively
disable it on other platforms. If there isn't a way to detect __func__
support automatically, then in the worst case the compiles would take a
-DFUNC_SUPPORTED (or whatever) as required, e.g.:
This is NOT what we use to call portable programming in this newsgroup.
And you can do better than that, considering that C99 and later
implementations are supposed to provide __func__, so you don't need any
hints from the user when using such compilers. And you can do even
better, by allowing other names for the same feature (some C89 compilers
supported this feature under a different name, e.g. __FUNCTION__ in the
case of gcc); it would be downright stupid to limit yourself to the
compilers using the __func__ identifier.
So, dump the idea of using FUNC_SUPPORTED and ask the user to define
FUNC itself, as appropriate for a C89 compiler supporting the feature.
/*
* Portable use (or non-use) of __func__ in debug mode
*/
#include <stdio.h>
//#define FUNC_SUPPORTED
//#define NDEBUG
#ifdef FUNC_SUPPORTED
#define FUNC __func__
#else
#define FUNC ""
#endif
Replace the above by:
#ifndef FUNC
#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
#define FUNC __func__
#else
#define FUNC "<unknown>"
#endif
#endif
Now, you are as flexible as you can be: if the user gives you a definition
for FUNC, you use it as such, otherwise you try to see if the compiler is
supposed to support __func__ for this purpose, if not, use the default
"<unknown>" name.
It's still not what I call portable code, since I have no guarantee that
I will ever see function names in the program's output. OTOH, it's
better than the guarantee that I'll *never* see function names in the
program's output.
Dan