【原创】G_STRLOC 宏
研究 MySQL Proxy 源码过程时，经常会看到类似下面这种调试打印：
------------------
之前遗漏了针对上述代码中 __GNUC__ 值的判定说明，glib 中代码注释如下：
------------------
现在问题变成了： __FILE__、 __LINE__、 __PRETTY_FUNCTION__、 __GNUC__ 和 __cplusplus 都是什么？ 可以参考下面的文章说明：
我们在写程序的时候，总是或多或少会加入一些 printf 之类的语句用于输出调试信息，但是 printf 语句有个很不方便的地方，就是当我们需要发布程序的时候，要一条一条的把这些语句删除，而一旦需要再次调试的时候，这些语句又不得不一条条的加上，这给我们带来了很大的不便，浪费了我们很多的时间，也造成了调试的效率低下。所以很多人会选择使用宏定义的方式来输出调试语句。
比如，定义一个宏开关：
如果我们能够把这三条语句编程一条，那该多舒服呀~，于是，我们想到使用这样的语句：
因此，我们希望 DEBUG 能够像 printf 那样，支持多个参数，并且这些参数刚好展开成为 printf 语句本身使用的参数，譬如我们希望 DEBUG("%s",msg) 能够展开为 printf("%s",msg) 。
【正文】
通过网上的资料查阅，发现自 C99 规范以后，编译器就开始支持不定参数的宏定义，就像 printf 一样。 大家可以看看这篇文章：http://blog.csdn.net/aobai219/archive/2010/12/22/6092292.aspx 。 （这个链接也转的，我已经找不到原始作者到底是谁了，唉，互联网啊。。。）
于是，我们定义了一个这样的东东：
于是乎，我们神奇地发现，DEBUG 完全取代了 printf ，所有的 DEBUG(…) 都被完成的替换成了 printf(…) ，再也不会因那个可恶的逗号而烦恼了。
但是，我们发现，光有 printf 还不够，虽然调试信息是输出了，可是很多的调试信息输出，我们并不能一下子知道这条信息到底是在那里打印出来的，于是，我们又想，能不能把当前所在文件名和源码行位置也打印出来呢，这样不就一目了然了吗，哪里还用的着去想，去找调试信息在哪里输出的呢，都已经打印出来了！
于是我们就有了下面的故事。。。
【编译器内置宏】
先介绍几个编译器内置的宏定义，这些宏定义不仅可以帮助我们完成跨平台的源码编写，灵活使用也可以巧妙地帮我们输出非常有用的调试信息。
ANSI C 标准中有几个标准预定义宏（也是常用的）：
看到这里，你的眼睛应该一亮了吧，嗯，是的，__FILE__ 和 __LINE__ 正是我们前面想要的输出的，于是，我们的每一条语句都变成了：
哈哈，是的，这就是本次大结局，把 DEBUG 写成这样：
============== __GNUC__、_MSC_VER ==================
【__GNUC__】
【 _MSC_VER】
if (0 != network_mysqld_con_command_states_init(con, &p)) {
g_debug("%s: ", G_STRLOC);
}
其中的
G_STRLOC 是什么呢？
查看 glib 的源码（glib-2.35.4），可知
#define G_STRINGIFY(macro_or_string) G_STRINGIFY_ARG (macro_or_string) #define G_STRINGIFY_ARG(contents) #contents上面是 glib 中对 Stringification 的定义，具体可以参阅 《 Stringification 在二级宏定义中的使用 》 。
/* Provide a string identifying the current code position */ #if defined(__GNUC__) && (__GNUC__ < 3) && !defined(__cplusplus) # define G_STRLOC __FILE__ ":" G_STRINGIFY (__LINE__) ":" __PRETTY_FUNCTION__ "()" #else # define G_STRLOC __FILE__ ":" G_STRINGIFY (__LINE__) #endif综上，G_STRLOC 是用于定位打印信息所在位置的宏。
------------------
之前遗漏了针对上述代码中 __GNUC__ 值的判定说明，glib 中代码注释如下：
#ifndef G_DISABLE_DEPRECATED
/* Wrap the gcc __PRETTY_FUNCTION__ and __FUNCTION__ variables with
* macros, so we can refer to them as strings unconditionally.
* usage not-recommended since gcc-3.0
*/
#if defined (__GNUC__) && (__GNUC__ < 3)
#define G_GNUC_FUNCTION __FUNCTION__
#define G_GNUC_PRETTY_FUNCTION __PRETTY_FUNCTION__
#else /* !__GNUC__ */
#define G_GNUC_FUNCTION ""
#define G_GNUC_PRETTY_FUNCTION ""
#endif /* !__GNUC__ */
#endif /* !G_DISABLE_DEPRECATED */
大致意思是：如果你没有通过定义宏 G_DISABLE_DEPRECATED 显式地要求不允许使用已经过时功能的话，那么在 gcc-3.0 之前的版本中，宏 __FUNCTION__ 和 __PRETTY_FUNCTION__ 是可用的，并且以字符串形式呈现。
------------------
现在问题变成了： __FILE__、 __LINE__、 __PRETTY_FUNCTION__、 __GNUC__ 和 __cplusplus 都是什么？ 可以参考下面的文章说明：
======= 我是分隔线 =========
【前言】我们在写程序的时候，总是或多或少会加入一些 printf 之类的语句用于输出调试信息，但是 printf 语句有个很不方便的地方，就是当我们需要发布程序的时候，要一条一条的把这些语句删除，而一旦需要再次调试的时候，这些语句又不得不一条条的加上，这给我们带来了很大的不便，浪费了我们很多的时间，也造成了调试的效率低下。所以很多人会选择使用宏定义的方式来输出调试语句。
比如，定义一个宏开关：
#define __DEBUG当需要调试的时候，使用语句：
#ifdef __DEBUG printf(xxx); #endif这种方式的调试，可以通过 #undef __DEBUG 的方式让告知编译器不编译这些语句，从而不再输出这些语句。但是这种方式的麻烦之处也是显而易见的，每一条调试语句都需要使用两条宏定义来包围，这不但在代码的编写上不便，源码结构也不好看，工作量依然不小。
如果我们能够把这三条语句编程一条，那该多舒服呀~，于是，我们想到使用这样的语句：
#ifdef __DEBUG #define DEBUG(info) printf(info) #else #define DEBUG(info) #endif这样，我们在编写代码的时候，使用 DEBUG 一条语句就可以了，我们把宏开关 __DEBUG 打开，所有的DEBUG(info) 宏定义信息都会被替换为 printf(info) ，关上则会被替换成空，因此不会被编译。嗯，这次方便多了，一条语句就可以了~~~。但是，问题也随之而来了，printf 是支持多个参数的，而且是不定参数，当你使用下面这样的语句时就会报错：
DEBUG("%s",msg)
这是因为，DEBUG(info) 这条宏定义只支持一个参数的替换。
因此，我们希望 DEBUG 能够像 printf 那样，支持多个参数，并且这些参数刚好展开成为 printf 语句本身使用的参数，譬如我们希望 DEBUG("%s",msg) 能够展开为 printf("%s",msg) 。
【正文】
通过网上的资料查阅，发现自 C99 规范以后，编译器就开始支持不定参数的宏定义，就像 printf 一样。 大家可以看看这篇文章：http://blog.csdn.net/aobai219/archive/2010/12/22/6092292.aspx 。 （这个链接也转的，我已经找不到原始作者到底是谁了，唉，互联网啊。。。）
于是，我们定义了一个这样的东东：
#define DEBUG(format, ...) printf (format, ##__VA_ARGS__)其中，' ## ' 的意思是，如果可变参数被忽略或为空，将使预处理器（ preprocessor ）去除掉它前面的那个逗号。
于是乎，我们神奇地发现，DEBUG 完全取代了 printf ，所有的 DEBUG(…) 都被完成的替换成了 printf(…) ，再也不会因那个可恶的逗号而烦恼了。
但是，我们发现，光有 printf 还不够，虽然调试信息是输出了，可是很多的调试信息输出，我们并不能一下子知道这条信息到底是在那里打印出来的，于是，我们又想，能不能把当前所在文件名和源码行位置也打印出来呢，这样不就一目了然了吗，哪里还用的着去想，去找调试信息在哪里输出的呢，都已经打印出来了！
于是我们就有了下面的故事。。。
【编译器内置宏】
先介绍几个编译器内置的宏定义，这些宏定义不仅可以帮助我们完成跨平台的源码编写，灵活使用也可以巧妙地帮我们输出非常有用的调试信息。
ANSI C 标准中有几个标准预定义宏（也是常用的）：
- __LINE__：在源代码中插入当前源代码行号；
- __FILE__：在源文件中插入当前源文件名；
- __DATE__：在源文件中插入当前的编译日期；
- __TIME__：在源文件中插入当前编译时间；
- __STDC__：当要求程序严格遵循ANSI C标准时该标识被赋值为1；
- __cplusplus：当编写 C++ 程序时该标识符被定义。
看到这里，你的眼睛应该一亮了吧，嗯，是的，__FILE__ 和 __LINE__ 正是我们前面想要的输出的，于是，我们的每一条语句都变成了：
DEBUG("FILE: %s, LINE: %d…",__FILE__,__LINE__,…)
其实没有必要，__FILE__ 本身就会被编译器置换为字符常量，于是乎我们的语句又变成了这样：
DEBUG("FILE:"__FILE__", LINE: %d…",__LINE__,…)
但是，我们还是不满足，依然发现，还是很讨厌，为什么每条语句都要写 "FILE:"__FILE__", LINE: %d" 以及 ",__LINE__," 这两个部分呢？这不是浪费我们时间么？
哈哈，是的，这就是本次大结局，把 DEBUG 写成这样：
DEBUG(format,...) printf("FILE: "__FILE__", LINE: %d: "format"/n", __LINE__, ##__VA_ARGS__)
没错，就是这样！下面，所有的 DEBUG 信息都会按照这样的方式输出：
FILE: xxx, LINE: xxx, …….最后，老规矩，coding测试。
#include <stdio.h>
#define __DEBUG__
#ifdef __DEBUG__
#define DEBUG(format, ...) printf("File: "__FILE__", Line: %05d "format"\n", __LINE__, ##__VA_ARGS__)
#else
#define DEBUG(format, ...)
#endif
int main()
{
char str[] = "Hello World";
DEBUG("A ha, check me: %s", str);
return 0;
} 输出结果[root@Betty Cpp_Code]# gcc print_debug_by_macro.cpp -lstdc++ [root@Betty Cpp_Code]# ./a.out File: print_debug_by_macro.cpp, Line: 00013 A ha, check me: Hello World
============== __GNUC__、_MSC_VER ==================
【__GNUC__】
- __GNUC__ 是 gcc 编译器编译代码时预定义的一个宏。需要针对 gcc 编写代码时， 可以使用该宏进行条件编译。
- __GNUC__ 值表示 gcc 的主版本号。针对 gcc 特定版本编写代码时，可使用该宏进行条件编译。
- __GNUC__ 的类型是 "int" ，该宏被扩展后得到的是整数字面值。可以通过预处理，查看宏扩展后的文本。
#include <assert.h>
#include <stdio.h>
#include <typeinfo>
#ifndef __GNUC__
#error sample for gcc compiler
#else
/* use gcc special extension: #warning , __attribute__, etc. */
#endif
int main()
{
printf("hello gcc %d\n",__GNUC__);
assert( typeid(__GNUC__)==typeid(int) );
printf("press Enter to exit\n");
(void)getchar();
} 【 _MSC_VER】
- _MSC_VER 是微软 C/C++ 编译器 -- cl.exe 编译代码时预定义的一个宏。需要针对 cl.exe 编写代码时， 可以使用该宏进行条件编译。
- _MSC_VER 的值表示 cl.exe 的版本。需要针对 cl.exe 特定版本编写代码时， 可使用该宏进行条件编译。
- _MSC_VER 的类型是 "int" 。该宏扩展后得到的是整数字面值。可以通过预处理， 查看宏扩展后的文本。
#include <stdio.h>
#include <stdlib.h>
#include <typeinfo>
#define TO_LITERAL(text) TO_LITERAL_(text)
#define TO_LITERAL_(text) #text
#ifndef _MSC_VER
#error sample for msvc compiler
#else
/* use msvc special extension: #pragma message,__declspec,__stdcall,etc. */
#pragma message("----------------------------------------\n")
#pragma message("----------------------------------------\n")
#pragma message("---------- hello msvc " TO_LITERAL(_MSC_VER) " -------------")
#pragma message("\n----------------------------------------\n")
#pragma message("----------------------------------------\n")
extern __declspec(dllimport) void __stdcall declare_but_dont_reference(void);
#endif
int main()
{
printf("hello msvc, version=%d\n",_MSC_VER);
printf("typeof _MSC_VER=\"%s\"\n",typeid(_MSC_VER).name());
system("pause"); /* msvc only on windows? */
return 0;
}
============== __PRETTY_FUNCTION__ ==================
GCC 编译器预定义了两个标识符存储当前函数的标识。
__FUNCTION__ 标识符只存储函数名字，__PRETTY_FUNCTION__ 则存储函数的全称。在 C 程序里，这两种名字是一样的，但是在 C++ 程序里它们有区别。
在 C++ 里，__FUNCTION__ 和 __PRETTY_FUNCTION__ 是变量，而不是宏定义，所以 #ifdef __FUNCTION__ 是没有意义的。
注意：如果你的 GCC 是 3.2 版本或更高，那么 __FUNCTION__ 和 __PRETTY_FUNCTION__ 的行为就和 C99 定义的 __func__ 变量是一样的。早于 3.2 版本的 GCC 编译器把 __FUNCTION__ 和 __PRETTY_FUNCTION__ 定义成字符串，所以它们可以和其他字符串进行串接操作。