Do we need __PRETTY_FUNCTION__ like macros in other compilers?

You might know that GCC in addition to __func__ macro, it supports __FUNCTION__ and __PRETTY_FUNCTION__. __func__ is the predefined-macro which contains the function name in a string. It is defined in C specs, But, __FUNCTION__ and __PRETY_FUNCTION__ are extensions by GCC. __FUNCTION__ macro is same as __func__. __PRETTY_FUNCTION__ macro gives the full function declaration including parameters and return values. I tried to look for other alternatives on SUNWspro compilers and HP-C/C++ but could not find any. Then I questioned myself ‘do we need this macro while we can always get sufficient debug information with __LINE__ , __FILE__, __func__??’.  Answer is ‘No’. We can always get sufficient debug information with the macros defined in specs. More over, if we use GCC extensions in code, portability to other platforms is a big pain. BTW, compiler also has a similar pre-defined macro for getting decorated function name.



  1. OpenAsthra said,

    May 29, 2007 at 6:48 am

    useful post!

  2. James said,

    June 24, 2007 at 7:14 am

    Please stop calling them macros. __func__ is explicitly not a macro in C99, and __FUNCTION__ and __PRETTY_FUNCTION__ in gcc are also not macros with C++ code and with gcc 3.4 and later.

    Also, your argument against not wanting __PRETTY_FUNCTION__-like behavior is odd, because by your reasoning, there’s no need for __func__ either; __FILE__ and __LINE__ always unambiguously provide sufficient information.

  3. Tony Garland said,

    September 6, 2007 at 1:21 am

    Something else to consider: when debugging C++ using templates, __PRETTY_FUNCTION__ will expand the template parameter with the actual template argument of the instantiation. This can be extremely helpful when debugging (for ASSERT support) because it tells you *which* template invocation of the particular function was invoked. You’ll never get this with a combination of __FUNCTION__, __FILE__, and __LINE__.

    So there is a good argument for having __PRETTY_FUNCTION__ where templates are being used.

  4. September 24, 2007 at 6:55 am

    The __func__ is really useful, but.. If one deals with C++ code where a function name may not uniquely identify a function (that may happen even within the same file), something like __class__ or __FUNCTION__ may be much better. You can call it any way you want, but we need to know a class name..

  5. refcode said,

    March 3, 2013 at 9:39 am

    nice one, useful.

  6. tbold said,

    April 10, 2013 at 6:59 pm

    To support the __PRETTY_FUNCTION__ argument consider this small utility:
    std::string real_name() {
    std::string name(__PRETTY_FUNCTION__);
    size_t op = name.find(‘=’);
    size_t cl = name.find(‘]’);
    return name.substr(op+1, cl-op-1);

    and elsewhere:

    is much more precise when it comes to templates than RTTI and cxxabi.

  7. Anonymoose said,

    March 18, 2016 at 6:13 am

    It’s not too hard to make a platform-agnostic version of the macro, if you want to use one.

    // Function signature helper.
    #if defined(_WIN32) || defined(_WIN64)
    #define FUNC_SIG __FUNCSIG__
    #elif defined(__unix__)
    #endif /* Function signature helper. */

    class PrettySig {
    void out() {
    std::cout << "I am " << std::endl
    << FUNC_SIG << std::endl
    << "Fear me!" << std::endl;

    int main() {
    PrettySig ps;

    • Anonymoose said,

      March 18, 2016 at 6:14 am

      That template should be:

      template<typename T, size_t N>

    • Anonymoose said,

      March 18, 2016 at 6:16 am

      Add other compiler equivalents to the macro as appropriate.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: