is there a location macro

[MoonKid]

I am using MinGW with C::B.

If a create messages (info, error, fatal, debug, log, etc) in my application I add a location parameter to it.
Here is an example:

Code Select Expand


void Class::DoSomething ()
{
  if ( something_is_wrong == TRUE )
     Message ("something is wrong", "Class::DoSomething()");
}


Is it possible to use a macro for the second parameter. That the preprocessor set the parameter itself?

Code Select Expand


     Message ("something is wrong", MACRO_CODELOCATION);


[mandrav]

Try __FUNCTION__ and __PRETTY_FUNCTION__ (the second one displays the non-mangled name, i.e. human-readable).

[MoonKid]

Try __FUNCTION__ and __PRETTY_FUNCTION__ (the second one displays the non-mangled name, i.e. human-readable).

Nice, but I am using wxWidgets and there
__FUNCTION__ is converted to L__FUNCTION__ because of the _() macro.

[sethjackson]

Try __FUNCTION__ and __PRETTY_FUNCTION__ (the second one displays the non-mangled name, i.e. human-readable).

Nice, but I am using wxWidgets and there
__FUNCTION__ is converted to L__FUNCTION__ because of the _() macro.

Use _T() instead?

[thomas]

Try __FUNCTION__ and __PRETTY_FUNCTION__ (the second one displays the non-mangled name, i.e. human-readable).

Nice, but I am using wxWidgets and there
__FUNCTION__ is converted to L__FUNCTION__ because of the _() macro.

Welcome to the wonderful world of wxWidgets, where macros grow and things never work as expected

But seriously, for once this is no wxWidgets' fault alone. The reason why this doesn't work is because __FUNCTION__ (unlike for example __FILE__) is technically not a preprocessor macro, but is a local const variable implicitly generated and implicitely replaced by the C/C++ translator at the compile stage, not at the preprocessor stage.
This has to do with the fact that a function's name may not be known to the preprocessor (due to name mangling and similar mechanisms).

Thus, _T(__FUNCTION__) will just do what you experienced, it will prepend L to the variable name which will of course fail. Macros are stupid, they just blindly replace text, and they don't care if it's legal or not.

Now, how to work around the problem? You have to evaluate and convert the variable at runtime. Unless you explicitely ask for something else (via a commandline option), gcc uses UTF-8. Thus, a line of code like this will do the job:

Code Select Expand

wxString s(__FUNCTION__, wxConvUTF8);