none
__FUNCTION__, __FUNCDNAME__ and __FUNCSIG__ macros

    Question

  • I posted this a while ago, but it seems to have disappeared from the forums.  As has the reply from Ayman Shoukry asking if it was still an issue.

    It is...

    None of these macros work!  I'm using the __FUNCTION__ macro to output the name of a function when tracing generic run-time errors, and it always expands to "__FSTREXP __FUNCTION__" .  All the others fail in a similar way - and I had such high hopes for using them!

    The fact that it does compile means that there's something wrong with the definition, or I guess it could be the way that I'm using it:  I'm stringizing the expansion and widening it (my app is pure unicode output) with the little widening macro trick that's in the MSDN:

    #define WIDEN2(x) L ## #x

    #define WIDEN(x) WIDEN2(x)

    Then I've defined another macro,

    # define __WFUNC__ WIDEN(__FUNCTION__)

    I have tried taking out the widening macro, and the result is the same.

    The editor can't actually resolve the definition (right-click->view definition)for __FUNCTION__, either, yet the tooltip displayed for the macro definition is #define __FUNCTION__() - but as I've already mentioned that doesn't tally with what I actually get.

    Could it be that the compiler is incorrectly setting a temporary string that is accessed by __FUNCTION__ when it expands?

    Or is there something more obvious to this?  I'm not using the /ep /p or compiler options (which suppress the macros' output), so that's not the problem either.

    Any ideas would be greatly appreciated.

    Thursday, June 08, 2006 1:56 AM

Answers

  • I just made a very simple HelloFunction program and it works as expected.

    int main(int argc, char *argv[])
    {
      cout << __FUNCTION__ << endl;
    }

    Is there a chancethat you have define your own __FUNCTION__ ?



    Thursday, June 08, 2006 6:17 AM
  • Hi Martin,

    I hadn't defined my own macro - but after reading your post I realised it must be something to do with my code, and the most likely candidate was the widening macro.

    So I changed the macro I'm using so that is doesn't use the __WIDEN__ macro and instead formats a unicode string using the '%S' format directive - thereby removing the need for any other compile-time mangling.

    Everything now works as expected. 

    I've also since discovered, (by doing a find in files in the VC++ include directories) that in order to widen the result, my widening macro needed to be slightly different:

    #define __STR2WSTR(str) L##str

    #define _STR2WSTR(str) __STR2WSTR(str)

    #define __FUNCTIONW__ _STR2WSTR(__FUNCTION__)

    This codesnippet is taken from an std header called yvals.h.  It's basically the same as the one I originally posted, but the __STR2WSTR macro has got one less '#' in it, so I guess the output I was getting was the stringizing of a macro that expanded to a macro, rather than a widening of the inner macro's string result.

    Great fun!

    At least that means now I can investigate making the generic exception management system (a la the .Net-related application blocks) that I wanted to make!

    Thanks for your help.

    Thursday, June 08, 2006 10:10 AM

All replies

  • I just made a very simple HelloFunction program and it works as expected.

    int main(int argc, char *argv[])
    {
      cout << __FUNCTION__ << endl;
    }

    Is there a chancethat you have define your own __FUNCTION__ ?



    Thursday, June 08, 2006 6:17 AM
  • Hi Martin,

    I hadn't defined my own macro - but after reading your post I realised it must be something to do with my code, and the most likely candidate was the widening macro.

    So I changed the macro I'm using so that is doesn't use the __WIDEN__ macro and instead formats a unicode string using the '%S' format directive - thereby removing the need for any other compile-time mangling.

    Everything now works as expected. 

    I've also since discovered, (by doing a find in files in the VC++ include directories) that in order to widen the result, my widening macro needed to be slightly different:

    #define __STR2WSTR(str) L##str

    #define _STR2WSTR(str) __STR2WSTR(str)

    #define __FUNCTIONW__ _STR2WSTR(__FUNCTION__)

    This codesnippet is taken from an std header called yvals.h.  It's basically the same as the one I originally posted, but the __STR2WSTR macro has got one less '#' in it, so I guess the output I was getting was the stringizing of a macro that expanded to a macro, rather than a widening of the inner macro's string result.

    Great fun!

    At least that means now I can investigate making the generic exception management system (a la the .Net-related application blocks) that I wanted to make!

    Thanks for your help.

    Thursday, June 08, 2006 10:10 AM
  • Hi Lord Zoltan,
    I was wondering if you could post the final fix you used to convert __FUNCTION__ to be Unicode compatible. I am struggling and failing miserably using the two suggestions you posted? Any code provided would be most helpful.
    Thanks in advance
    Ganesh
    Wednesday, October 31, 2007 5:45 PM
  • Hi Lord Zoltan,
    I was wondering if you could post the final fix you used to convert __FUNCTION__ to be Unicode compatible. I am struggling and failing miserably using the two suggestions you posted? Any code provided would be most helpful.
    Thanks in advance
    Ganesh


    To answer a long-time-ago question:

    TEXT(__FUNCTION__)
    

    That's your macro.

    Sources:
    http://msdn.microsoft.com/en-us/library/dd374074(v=vs.85).aspx
    http://msdn.microsoft.com/en-us/library/b0084kay(v=VS.100).aspx

    Monday, March 07, 2011 2:28 AM