研究 MySQL Proxy 源码过程时，经常会看到类似下面这种调试打印：
|
1 2 3 |
|
其中的 G_STRLOC 是什么呢？ 查看 glib 的源码（glib-2.35.4），可知
|
1 2 |
|
上面是 glib 中对 Stringification 的定义，具体可以参阅《Stringification 在二级宏定义中的使用》。
|
1 2 3 4 5 6 |
|
综上，G_STRLOC 是用于定位打印信息所在位置的宏。
------------------
之前遗漏了针对上述代码中 __GNUC__ 值的判定说明，glib 中代码注释如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
大致意思是：如果你没有通过定义宏 G_DISABLE_DEPRECATED 显式地要求不允许使用已经过时功能的话，那么在 gcc-3.0 之前的版本中，宏 __FUNCTION__ 和 __PRETTY_FUNCTION__ 是可用的，并且以字符串形式呈现。
------------------
现在问题变成了： __FILE__、 __LINE__、 __PRETTY_FUNCTION__、 __GNUC__ 和 __cplusplus 都是什么？ 可以参考下面的文章说明：
======= 我是分隔线 =========
【前言】
我们在写程序的时候，总是或多或少会加入一些 printf 之类的语句用于输出调试信息，但是 printf 语句有个很不方便的地方，就是当我们需要发布程序的时候，要一条一条的把这些语句删除，而一旦需要再次调试的时候，这些语句又不得不一条条的加上，这给我们带来了很大的不便，浪费了我们很多的时间，也造成了调试的效率低下。所以很多人会选择使用宏定义的方式来输出调试语句。
比如，定义一个宏开关：
|
1 |
|
当需要调试的时候，使用语句：
|
1 2 3 |
|
这种方式的调试，可以通过 #undef __DEBUG 的方式让告知编译器不编译这些语句，从而不再输出这些语句。但是这种方式的麻烦之处也是显而易见的，每一条调试语句都需要使用两条宏定义来包围，这不但在代码的编写上不便，源码结构也不好看，工作量依然不小。
如果我们能够把这三条语句编程一条，那该多舒服呀~，于是，我们想到使用这样的语句：
|
1 2 3 4 5 |
|
这样，我们在编写代码的时候，使用 DEBUG 一条语句就可以了，我们把宏开关 __DEBUG 打开，所有的DEBUG(info) 宏定义信息都会被替换为 printf(info) ，关上则会被替换成空，因此不会被编译。嗯，这次方便多了，一条语句就可以了~~~。但是，问题也随之而来了，printf 是支持多个参数的，而且是不定参数，当你使用下面这样的语句时就会报错：
|
1 |
|
这是因为，DEBUG(info) 这条宏定义只支持一个参数的替换。
因此，我们希望 DEBUG 能够像 printf 那样，支持多个参数，并且这些参数刚好展开成为 printf 语句本身使用的参数，譬如我们希望 DEBUG("%s",msg) 能够展开为 printf("%s",msg) 。
【正文】
通过网上的资料查阅，发现自 C99 规范以后，编译器就开始支持不定参数的宏定义，就像 printf 一样。 大家可以看看这篇文章：http://blog.csdn.net/aobai219/archive/2010/12/22/6092292.aspx 。 （这个链接也转的，我已经找不到原始作者到底是谁了，唉，互联网啊。。。）
于是，我们定义了一个这样的东东：
|
1 |
|
其中，' ## ' 的意思是，如果可变参数被忽略或为空，将使预处理器（ preprocessor ）去除掉它前面的那个逗号。
于是乎，我们神奇地发现，DEBUG 完全取代了 printf ，所有的 DEBUG(…) 都被完成的替换成了 printf(…) ，再也不会因那个可恶的逗号而烦恼了。
但是，我们发现，光有 printf 还不够，虽然调试信息是输出了，可是很多的调试信息输出，我们并不能一下子知道这条信息到底是在那里打印出来的，于是，我们又想，能不能把当前所在文件名和源码行位置也打印出来呢，这样不就一目了然了吗，哪里还用的着去想，去找调试信息在哪里输出的呢，都已经打印出来了！
于是我们就有了下面的故事。。。
【编译器内置宏】
先介绍几个编译器内置的宏定义，这些宏定义不仅可以帮助我们完成跨平台的源码编写，灵活使用也可以巧妙地帮我们输出非常有用的调试信息。
ANSI C 标准中有几个标准预定义宏（也是常用的）：
- __LINE__：在源代码中插入当前源代码行号；
- __FILE__：在源文件中插入当前源文件名；
- __DATE__：在源文件中插入当前的编译日期；
- __TIME__：在源文件中插入当前编译时间；
- __STDC__：当要求程序严格遵循ANSI C标准时该标识被赋值为1；
- __cplusplus：当编写 C++ 程序时该标识符被定义。
编译器在进行源码编译的时候，会自动将这些宏替换为相应内容。
看到这里，你的眼睛应该一亮了吧，嗯，是的，__FILE__ 和 __LINE__ 正是我们前面想要的输出的，于是，我们的每一条语句都变成了：
|
1 |
|
其实没有必要，__FILE__ 本身就会被编译器置换为字符常量，于是乎我们的语句又变成了这样：
|
1 |
|
但是，我们还是不满足，依然发现，还是很讨厌，为什么每条语句都要写 "FILE:"__FILE__", LINE: %d" 以及 ",__LINE__," 这两个部分呢？这不是浪费我们时间么？
哈哈，是的，这就是本次大结局，把 DEBUG 写成这样：
|
1 |
|
没错，就是这样！下面，所有的 DEBUG 信息都会按照这样的方式输出：
|
1 |
|
最后，老规矩，coding测试。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
输出结果
|
1 2 3 |
|
============== __GNUC__、_MSC_VER ==================
【__GNUC__】
- __GNUC__ 是 gcc 编译器编译代码时预定义的一个宏。需要针对 gcc 编写代码时， 可以使用该宏进行条件编译。
- __GNUC__ 值表示 gcc 的主版本号。针对 gcc 特定版本编写代码时，可使用该宏进行条件编译。
- __GNUC__ 的类型是 "int" ，该宏被扩展后得到的是整数字面值。可以通过预处理，查看宏扩展后的文本。
示例：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
【 _MSC_VER】
- _MSC_VER 是微软 C/C++ 编译器 -- cl.exe 编译代码时预定义的一个宏。需要针对 cl.exe 编写代码时， 可以使用该宏进行条件编译。
- _MSC_VER 的值表示 cl.exe 的版本。需要针对 cl.exe 特定版本编写代码时， 可使用该宏进行条件编译。
- _MSC_VER 的类型是 "int" 。该宏扩展后得到的是整数字面值。可以通过预处理， 查看宏扩展后的文本。
示例：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
============== __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__ 定义成字符串，所以它们可以和其他字符串进行串接操作。