呵呵，那你得探索一下宏的使用技巧～ 不是你这么写的。
一般函数体定义呀，头文件呀，和调用到它们的模块一般不是写一个文件里的吧～
那个替换写在头文件里就行了。
我说了这个办法可能也不是很好，我的灵感是这么来的：
GNU 旗下有很多开源工具的源码我看过不少，其中有的全局工具其实是 unix 的一些系统调用呀，GNU 库里的东西。GNU 为了增加工具的可移植性，让没有的这些系统调用的系统也能用，就自己实现了一个功能类似的函数。不过声明头里说里，如果你在类 UNIX 的系统下编译软件时，可以在 configure 时提供 --with-gnu-libc 参数，避免编译那些没用的 code，不过它主要是应用到 make 上。我当时就想类似的技术用到编译上也一样。
我当时举的那个例子是为了简单，才写在一起的。你如果写在头文件里，每个包含的文件就都会预处理。像你那么写，因为有顺序，所以在下面出现的替换上面是不会应用的。
还有另一个概念就是，我当时是希望调试的东西只在调试的时候生效，把 DEBUG 这个宏定义在环境里。当调试结束之后，去掉这个宏，再重新编译就可以得到发布版的程序。而不搀杂调试函数。
而我现在知道你是希望这两个函数能同时存在在。才会写类似
#define c1 c2
c1.dump();
test();
#undef c1
c1.dump();
的代码。
我当时并没有考虑你既要调 f() 作为 f()，也要调 f() 作为 _f() 。所以我提供的那个办法可能根本行不通。
一般函数体定义呀，头文件呀，和调用到它们的模块一般不是写一个文件里的吧～
那个替换写在头文件里就行了。
我说了这个办法可能也不是很好，我的灵感是这么来的：
GNU 旗下有很多开源工具的源码我看过不少，其中有的全局工具其实是 unix 的一些系统调用呀，GNU 库里的东西。GNU 为了增加工具的可移植性，让没有的这些系统调用的系统也能用，就自己实现了一个功能类似的函数。不过声明头里说里，如果你在类 UNIX 的系统下编译软件时，可以在 configure 时提供 --with-gnu-libc 参数，避免编译那些没用的 code，不过它主要是应用到 make 上。我当时就想类似的技术用到编译上也一样。
我当时举的那个例子是为了简单，才写在一起的。你如果写在头文件里，每个包含的文件就都会预处理。像你那么写，因为有顺序，所以在下面出现的替换上面是不会应用的。
还有另一个概念就是，我当时是希望调试的东西只在调试的时候生效，把 DEBUG 这个宏定义在环境里。当调试结束之后，去掉这个宏，再重新编译就可以得到发布版的程序。而不搀杂调试函数。
而我现在知道你是希望这两个函数能同时存在在。才会写类似
#define c1 c2
c1.dump();
test();
#undef c1
c1.dump();
的代码。
我当时并没有考虑你既要调 f() 作为 f()，也要调 f() 作为 _f() 。所以我提供的那个办法可能根本行不通。
