I want to know how to find out if the preprocessor macro __PRETTY_FUNCTION__ can be used with a given compiler (As it is supposed to be non-standard). How do I check this in a header file? What I want to do is something like:
#ifndef __PRETTY_FUNCTION__
#define __PRETTY_FUNCTION__ __func__
#endif
But, I'm guessing what happens is the preprocessor defines the macro in place for each function so I wonder whether there's any meaning to __PRETTY_FUNCTION__ (Unlike __FILE__ or __LINE__) outside a function. Is this true or can I just use the code above? If not, how do I check for it?
EDIT: I tried it. __PRETTY_FUNCTION__ is undefined outside a function (I didn't check inside a class). So there has to be another way.
EDIT2: Actually a simple hack would be to do this :):
void Dummy()
{
#ifndef __PRETTY_FUNCTION__
#define __PRETTY_FUNCTION__ __func__
#endif
}
The other method is to check for compiler as was suggested by others.
You probably have to know which compiler you're using. For GCC (the GNU Compiler Collection), you'd probably test:
#ifdef __GNUG__
...use __PRETTY_FUNCTION__
#endif
You might check the compiler version if you know which one introduced the feature and you are in any danger of having your code compiled with an older version.
The GCC (4.4.1) manual says:
In C, __PRETTY_FUNCTION__ is yet another name for __func__. However, in C++, __PRETTY_FUNCTION__ contains the type signature of the function as well as its bare name.
For example, this program:
extern "C" {
extern int printf (char *, ...);
}
class a {
public:
void sub (int i)
{
printf ("__FUNCTION__ = %s\n", __FUNCTION__);
printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__);
}
};
int
main (void)
{
a ax;
ax.sub (0);
return 0;
}
gives this output:
__FUNCTION__ = sub
__PRETTY_FUNCTION__ = void a::sub(int)
These identifiers are not preprocessor macros. In GCC 3.3 and earlier, in C only, __FUNCTION__ and __PRETTY_FUNCTION__ were treated as string literals; they could be used
to initialize char arrays, and they could be concatenated with other string literals. GCC
3.4 and later treat them as variables, like __func__. In C++, __FUNCTION__ and __PRETTY_
FUNCTION__ have always been variables.
Related
Where in GCC is the behavior of C++’s __PRETTY_FUNCTION__ defined? I want to replicate its functionality in Visual Studio.
It’s my understanding that I could replace __PRETTY_FUNCTION__ with either __FUNCTION__ or __FUNCSIG__,¹ but that, then, I’d lose the ability to compile the code on macOS.
How do include __PRETTY_FUNCTION__’s functionality in code that I want to be able to compile in, say, both Visual Studio and Xcode.
Apologies if the answer to my question is in the text I’m linking to or in the resources it mentions.
Define your own macro that refers to __FUNCTION__ or __PRETTY_FUNCTION__ based on your compiler:
#ifdef _MSC_VER
#define MY_FUNCTION_MACRO __FUNCTION__ // or __FUNCSIG__
#else
#define MY_FUNCTION_MACRO __PRETTY_FUNCTION__
#endif
And then use MY_FUNCTION_MACRO throughout your cross-patform code.
Note that MY_FUNCTION_MACRO will still produce different strings from between VC++ and GCC/Clang. This is unavoidable and gets you as close as you can get.
For example:
int main()
{
std::cout << MY_FUNCTION_MACRO << std::endl;
}
will produce "main" when using __FUNCTION__ or "int __cdecl main(void)" when using __FUNCSIG__ in VC++, whereas __PRETTY_FUNCTION__ produces "int main()" in GCC/Clang.
I was wondering about this myself, found your post, and did some more digging. Here's some answers and more that I discovered...
Where in GCC is the behavior of C++’s __PRETTY_FUNCTION__ defined?
A recursive search for __PRETTY_FUNCTION__ within the gcc source code mirrored on github suggested that its behavior is mostly defined through DECL_PRETTY_FUNCTION_P in gcc/cp/pt.cc. This in turn sees to cp_make_fname_decl being invoked from gcc/cp/decl.cc. And that builds a declaration for __PRETTY_FUNCTION__.
Currently - as of my reading of this code and experience using __PRETTY_FUNCTION__ - gcc provides a locally scoped, read only, constant expression, character array type of value.
I.e., by its naming convention, __PRETTY_FUNCTION__ may look like a macro (that's what I'd assumed), but by its current implementation (in gcc), it's instead a locally scoped, character array.
How do I include __PRETTY_FUNCTION__’s functionality in code that I want to be able to compile in, say, both Visual Studio and Xcode?
Xcode by default I understand is using an Apple version of clang. Clang is more similar to gcc with respect to this question, than to msvc. So if by Xcode, you mean to use the default compiler, that'd be clang which similarly supports __PRETTY_FUNCTION__.
With this in mind, I like cscrimage's answer using __FUNCSIG__ for msvc and __PRETTY_FUNCTION__ otherwise:
#ifdef _MSC_VER
#define MY_FUNCTION_MACRO __FUNCSIG__
#else
#define MY_FUNCTION_MACRO __PRETTY_FUNCTION__
#endif
What To Expect
Using the abort sort of code within a function such as the following demonstrates the formats of these values for different compilers:
template <typename T> std::string Name()
{
#if defined(__clang__) || defined(__GNUC__)
return std::string {__PRETTY_FUNCTION__};
#elif defined(_MSC_VER)
return std::string {__FUNCSIG__};
#else
return "not supported by compiler";
#endif
}
template <typename T> struct Other {};
using F = Other<int>;
A statement like:
std::cout << Name<F>() << '\n';
On gcc 12.2 yields:
std::string Name() [with T = Other<int>; std::string = std::__cxx11::basic_string<char>]
And on msvc 19.22 yields:
class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl Name<struct Other<int>>(void)
That's pretty compiler dependent and clang is slightly different from gcc as well.
Normalizing The Values
We could however use something like std::regex_replace with compiler dependent std::regex values to parse these into a more similar format between these compilers. I didn't find any documentation from gcc nor msvc that guaranteed what this format will be so I wouldn't expect it to stay the same between all releases of compilers either.
In my case (that got me to dig into this), I was particularly concerned about stringifying types and built on these techniques using the template type parameter as the value I intended to return from the replacement. Here's that code as an example that accounts for differences between msvc, clang, and gcc:
template <typename T>
std::string Name()
{
// Ideally return string unique to the type T...
#if defined(_MSC_VER)
// template <typename T> string Name() { return string{__FUNCSIG__}; }
// enum class Fruit {APPLE, PEAR};
// std::cout << Name<Fruit>() << '\n';
// produces:
// class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl Name<enum Fruit>(void)
return std::regex_replace(__FUNCSIG__, std::regex(".* __cdecl [^<]+<(.*)>\\(void\\)"), "$1");
#elif defined(__clang__)
// template <typename T> string Name() { return string{__PRETTY_FUNCTION__}; }
// enum class Fruit {APPLE, PEAR};
// std::cout << Name<Fruit>() << '\n';
// produces: std::string Name() [T = Fruit]
return std::regex_replace(__PRETTY_FUNCTION__, std::regex(".*T = (.*)\\].*"), "$1");
#elif defined(__GNUC__)
// template <typename T> string Name() { return string{__PRETTY_FUNCTION__}; }
// enum class Fruit {APPLE, PEAR};
// std::cout << Name<Fruit>() << '\n';
// produces: std::string Name() [with T = Fruit; std::string = std::__cxx11::basic_string<char>]
return std::regex_replace(__PRETTY_FUNCTION__, std::regex(".*T = (.*);.*"), "$1");
#else
return {}; // not unique but maybe still helpful at avoiding compiler issues
#endif
}
template <typename T> struct Other {};
using F = Other<int>;
int main()
{
std::cout << Name<F>() << '\n';
}
With that, on gcc 12.2 and clang trunk we get Other<int>, and on msvc 19.22 we get struct Other<int> - see the full code at godbolt. This was close enough for my purposes.
Regular expressions for instead returning a commonly formatted function signature looks more involved (depending of course on exactly how common a format one wants) but I don't see why that couldn't be done also.
Some Alternatives
If you can use boost, you may want to look into BOOST_CURRENT_FUNCTION or boost::core::demangle depending on whether you just want code to pick the variable for you to use on your platforms or whether you're more interested in re-using code that's already been written to give you the formatting. And if you have RTTI enabled, you can use something like boost::core::demangle(typeid(T).name()). I notice however that for functions, this will strip off the function name and just provide a readable function signature for it. It also seems like demangle used between clang and msvc isn't returning a completely platform independent signature for the function either.
Or, if you can use C++20 or newer and it's the function signature and name you're wanting, std::source_location::function_name looks interesting. It's implementation defined too however.
The following code,
#include <iostream>
#ifndef __func__
# ifdef __FUNCTION__
# define __func__ __FUNCTION__
# else
//# error This compiler supports neither __func__ nor __FUNCTION__
# endif
#endif
int main(int argc, char **argv)
{
std::cout << __func__ << std::endl
<< __FUNCTION__ << std::endl
<< __PRETTY_FUNCTION__ << std::endl;
}
gives the following expected output,
main
main
int main(int, char**)
However, if I uncomment the else condition, compilation fails because neither __func__ nor __FUNCTION__ are defined. How can this be? They clearly are defined as seen in the output above. Is there some simple principle regarding #ifdef/#ifndef that I'm missing here?
__func__ is not a macro. It is a magic variable, as are __FUNCTION__ and __PRETTY_FUNCTION__.
From https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Function-Names.html:
GCC provides three magic variables that hold the name of the current function, as a string. The first of these is __func__, which is part of the C99 standard:
The identifier __func__ is implicitly declared by the translator as if, immediately following the opening brace of each function definition, the declaration
static const char __func__[] = "function-name";
...
__FUNCTION__ is another name for __func__.
...
In C, __PRETTY_FUNCTION__ is yet another name for __func__. However, in C++, __PRETTY_FUNCTION__ contains the type signature of the function as well as its bare name.
GCC compiler gives me the following macros:
__FILE__ so that I can print out the file name + directory.
__LINE__ so that I can print out the line number of where I'm printing from.
__PRETTY_FUNCTION__ so that I can print out the pretty function name
Does Visual C++ have the equivalent of these macros? A side question is, are these standard for C++ compilers?
In VS2008, this:
struct A
{
bool Test(int iDummyArg)
{
const char *szFile = __FILE__;
int iLine = __LINE__;
const char *szFunc = __FUNCTION__; // Func name
const char *szFunD = __FUNCDNAME__; // Decorated
const char *szFunS = __FUNCSIG__; // Signature
printf("%s\n", szFile);
printf("%d\n", iLine);
printf("%s\n", szFunc);
printf("%s\n", szFunD);
printf("%s\n", szFunS);
return true;
}
};
int wmain(int argc, TCHAR *lpszArgv[])
{
A a;
a.Test(10);
}
will print this:
c:\source\test_projects\blah\blah.cpp
14
A::Test
?Test#A##QAE_NH#Z
bool __thiscall A::Test(int)
(The line number is "wrong" since there was really some extra stuff at the top of my file.)
__FILE__ and __LINE__ are standard, and I'm rather certain Microsoft compilers have essentially always had them.
__PRETTY_FUNCTION__ is a gcc feature.
For more portability in getting the current function name, you can try BOOST_CURRENT_FUNCTION.
Yes Visual C++ has them or an equivalent. See the responses here:
What's the difference between __PRETTY_FUNCTION__, __FUNCTION__, __func__?
function-func/4384860#4384860
Also note that despite the upper case used, they aren't macros. They're variables.
I know that MSVC offers __FILE__ and __LINE__, both of which are Standard macros. They also offer __FUNCTION__, which I believe is what you're looking for,
__FILE__ and __LINE__ are standard since C89. __PRETTY_FUNCTION__ is a GCCism. __func__ is a C99ism which (unlike GCCisms) may well be available in Visual C++; it is not precisely the same as __PRETTY_FUNCTION__ but it may be close enough for your purposes.
Yes, Microsoft Visual Studio has __FILE__ and __LINE__. Here are more MSVC macros.
Both are ANSI C++.
MSVC has __FUNCTION__, which is Microsoft-specific.
Using c++14 with constexpr you can use this: WHERE macro.
Based on usage of:
__PRETTY_FUNCTION__
__LINE__
#include "string/ConstexprString.hpp"
#define S1(x) #x
#define S2(x) S1(x)
// WHERE - const char* const should be used as temporary value
#define WHERE (string::make(__PRETTY_FUNCTION__) + ":" + string::make(S2(__LINE__))).get()
// It is safe to store e.g. `constexpr auto where = WHERE_STR;`
#define WHERE_STR (string::make(__PRETTY_FUNCTION__) + ":" + string::make(S2(__LINE__)))
Example usage:
// Called: void (anonymous namespace)::exampleUseCaseWhere(int):18
std::cout << "Called: " << WHERE << std::endl;
Full & running example here
See:
src/acme/where.hpp
src/string/ConstexprString.hpp
src/acme/where_test.cpp
Can anyone tell when g++ replaces the __FUNCTION__ 'macro' with the string containing the function name? It seems it can replace it not until it has check the syntactical correctness of the source code, i.e. the following will not work
#include <whatsneeded>
#define DBG_WHEREAMI __FUNCTION__ __FILE__ __LINE__
int main(int argc, char* argv)
{
printf(DBG_WHEREAMI "\n"); //*
}
since after preprocessing using
g++ -E test.cc
the source looks like
[...]
int main(int argc, char* argv)
{
printf(__FUNCTION__ "test.cc" "6" "\n"); //*
}
and now the compiler rightly throws up because the *ed line is incorrect.
Is there any way to force that replacement with a string to an earlier step so that the line is correct?
Is __FUNCTION__ really replaced with a string after all? Or is it a variable in the compiled code?
Is there any way to force that replacement with a string to an earlier step so that the line is correct?
No. __FUNCTION__ (and its standardized counterpart, __func__) are compiler constructs. __FILE__ and __LINE__ on the other hand, are preprocessor constructs. There is no way to make __FUNCTION__ a preprocessor construct because the preprocessor has no knowledge of the C++ language. When a source file is being preprocessed, the preprocessor has absolutely no idea about which function it is looking at because it doesn't even have a concept of functions.
On the other hand, the preprocessor does know which file it is working on, and it also knows which line of the file it is looking at, so it is able to handle __FILE__ and __LINE__.
This is why __func__ is defined as being equivalent to a static local variable (i.e. a compiler construct); only the compiler can provide this functionality.
You are using __FUNCTION__ like a preprocessor macro, but it's a variable (please read http://gcc.gnu.org/onlinedocs/gcc/Function-Names.html).
Try printf("%s", __FUNCTION__) just for testing and it will print the function name.
__FUNCTION__ is not standard. Use __func__. As the documentation says, it's as if:
<ret-type> function_name( <args> )
{
static const char __func__[] = "function-name";
...
In C/C++, the preprocessor will turn "my " "name " "is " "Bob" into the string literal "my name is Bob"; since __FILE__ and __LINE__ are preprocessor instructions, "We are on line " __LINE__ will pass "We are on line 27" to the compiler.
__FUNCTION__ is normally a synonym for __func__. __func__ can be thought of as a pseudo-function that returns the name of the function in which it is called. This can only be done by the compiler and not by the preprocessor. Because __func__ is not evaluated by the preprocessor, you do not get automatic concatenation. So if you are using printf it must be done by printf("the function name is %s", __func__);
Is this what you want?
#include <stdio.h>
#define DBG_WHEREAMI(X) printf("%s %s(%d): %s\n",__func__,__FILE__,__LINE__,X)
int main(int argc, char* argv)
{
DBG_WHEREAMI("Starting");
}
Note: Since you marked this as C++ you should probably be using the iostreams to make sure it's type safe.
printf("%s" __FILE__ __LINE__ "\n", __FUNCTION__);
Yeah, I know that's not really the same.
Note that if you create a class, you can build a message from any number of types as you'd like which means you have a similar effect to the << operator or the format in a printf(3C). Something like this:
// make sure log remains copyable
class log
{
public:
log(const char *function, const char *filename, int line)
{
f_message << function << ":" << filename << ":" << line << ": ";
}
~log()
{
//printf("%s\n", f_message.str().c_str()); -- printf?!
std::cerr << f_message.str() << std::endl;
}
log& operator () (const char *value)
{
f_message << value;
}
log& operator () (int value)
{
f_message << value;
}
// repeat with all the types you want to support in the base class
// (should be all the basic types at least)
private:
sstream f_message;
};
// start the magic here
log log_error(const char *func, const char *file, int line)
{
log l(func, file, line);
return l;
}
// NOTE: No ';' at the end here!
#define LOG_DEBUG log_error(__func__, __FILE__, __LINE__)
// usage sample:
LOG_DEBUG("found ")(count)(" items");
Note that you could declare the << operators instead of the (). In that case the resulting usage would be something like this:
LOG_DEBUG << "found " << count << " items";
Depends which you prefer to use. I kind of like () because it protects your expressions automatically. i.e. if you want to output "count << 3" then you'd have to write:
LOG_DEBUG << "found " << (count << 3) << " items";
__FILE__ and __LINE__ are well known. There is a __func__ since C99.
#include <iostream>
struct Foo {
void Do(){ std::cout << __func__ << std::endl; }
};
int main()
{
std::cout << __func__ << std::endl;
Foo foo; foo.Do();
return 0;
}
will output
main
Do
Is there any macro / keyword that would output method name like Foo::Do?
Boost has a special utility macro called BOOST_CURRENT_FUNCTION that hides the differences between the compiler implementations.
Following it's implementation we see that there are several macros depending on compiler:
__PRETTY_FUNCTION__ -- GCC, MetroWerks, Digital Mars, ICC, MinGW
__FUNCSIG__ -- MSVC
__FUNCTION__ -- Intel and IBM
__FUNC__ -- Borland
__func__ -- ANSI C99
On GCC you can use __FUNCTION__ and
__PRETTY_FUNCTION__.
On MSVC you can use __FUNCSIG__ and __FUNCTION__.
There's no such macro in standard C++, and that includes the draft C++0x standard I looked at. It would complicate compilation, since parsing (necessary to determine what a function is) comes after preprocessing, and I suspect that's why there's nothing in the standard.
The __func__ you're using is nonstandard, although it apparently works on your compiler.
Not in Standard C++ (and __func__ is not part of C++). Your implementation may have such a feature though - which compiler are you using?
See "Predefined Macros (C/C++)" for a complete list supported by MS Visual Studio.
This might be useful:
http://gcc.gnu.org/onlinedocs/gcc/Function-Names.html
#include"stdio.h"
#include"stdlib.h"
int main()
{
printf("line number is %d .. func name is %s, file name is %s",__LINE__,__PRETTY_FUNCTION__,__FILE__);
return 0;
}
This is how to print line number, function name and file name in gcc.