为什么很多大牛在写题的时候要加一堆宏？

给你说几个 inline 无法代替宏的地方：

1. 循环展开：

// loop unroll double#define LOOP_UNROLL_DOUBLE(action, actionx2, width) do { \unsigned long __width = (unsigned long)(width); \unsigned long __increment = __width >> 2; \for (; __increment > 0; __increment--) { \actionx2;\actionx2;\}\switch (__width & 3) { \case 2: actionx2; break; \case 3: actionx2; \case 1: action; break; \}\}while (0)// loop unroll quatro#define LOOP_UNROLL_QUATRO(action, actionx2, actionx4, width) do { \unsigned long __width = (unsigned long)(width);\unsigned long __increment = __width >> 2; \for (; __increment > 0; __increment--) { \actionx4;\}\switch (__width & 3) { \case 2: actionx2; break; \case 3: actionx2; \case 1: action; break; \}\}while (0)

假设你需要高速循环做一个事情，那么展开循环可以极大的减少CPU分支，并且充分利用CPU流水线的并行效果，比如你开发一个 FIR滤波器来处理信号，那么你的代码如果从 for (...) { .... } 变成循环展开的话，可以这么写：

LOOP_UNROLL_DOUBLE({x = *src++;// do something with x and h and output to y*dst++ = y;},{x1 = *src++;x2 = *src++;// do something with x1 and h and output to y1// do something with x2 and h and output to y2*dst++ = y1;*dst++ = y2;},nsamples,);

如此写法将每个循环只计算一个 sample，变为每个循环同时计算两个sample，分开写代码，也能更好的利用 SIMD去加速同时多个 sample的计算过程，这就是利用循环展开来优化性能的用法，直接传 "{...}" 里面的运行代码给宏，宏不变，但是每处使用LOOP_UNROLL的地方 "{.. } " 中的代码都是不同的，inline是代替不了的，你总不至于传个函数指针过去吧，这时性能优化方面情况。

2. 函数组装：

想象一下，你写图形图像的代码，现在你需要给像素合成实现 SRC_ATOP， SRC_OVER, SRC_IN, SRC_OUT, DST_ATOP, DST_OVER, DST_IN, DST_OUT, XOR, PLUS, ALLANON, TINT, DIFF, DARKEN, LIGHTEN, SCREEN, OVERLAY 等等 二十种像素合成的方法，你如果不用宏，那么你需要写多少个函数？20多个看起来类似的函数，你不得写疯了么？此时用函数指针其实是很浪费性能的事情，那么该如何写呢？你可以规定一系列用来计算composite的方法，接受两组 RGBA，生成新的，比如：

/* compositing */#define IBLEND_COMPOSITE(sr, sg, sb, sa, dr, dg, db, da, FS, FD) do { \(dr) = _ipixel_mullut[(FS)][(sr)] + _ipixel_mullut[(FD)][(dr)]; \(dg) = _ipixel_mullut[(FS)][(sg)] + _ipixel_mullut[(FD)][(dg)]; \(db) = _ipixel_mullut[(FS)][(sb)] + _ipixel_mullut[(FD)][(db)]; \(da) = _ipixel_mullut[(FS)][(sa)] + _ipixel_mullut[(FD)][(da)]; \}while (0)/* premultiply: src over */#define IBLEND_OP_SRC_OVER(sr, sg, sb, sa, dr, dg, db, da) do { \IUINT32 FD = 255 - (sa); \IBLEND_COMPOSITE(sr, sg, sb, sa, dr, dg, db, da, 255, FD); \}while (0)/* premultiply: dst atop */#define IBLEND_OP_DST_ATOP(sr, sg, sb, sa, dr, dg, db, da) do { \IUINT32 FS = 255 - (da); \IUINT32 FD = (sa); \IBLEND_COMPOSITE(sr, sg, sb, sa, dr, dg, db, da, FS, FD); \}while (0)/* premultiply: dst in */#define IBLEND_OP_DST_IN(sr, sg, sb, sa, dr, dg, db, da) do { \IUINT32 FD = (sa); \IBLEND_COMPOSITE(sr, sg, sb, sa, dr, dg, db, da, 0, FD); \}while (0)

然后用 #连接各种方法和格式，生成不同的函数，比如：

#define IPIXEL_COMPOSITE_FN(name, opname) \static void ipixel_comp_##name(IUINT32 *dst, const IUINT32 *src, int w)\{ \IUINT32 sr, sg, sb, sa, dr, dg, db, da; \for (; w > 0; dst++, src++, w--) { \_ipixel_load_card(src, sr, sg, sb, sa); \_ipixel_load_card(dst, dr, dg, db, da); \IBLEND_OP_##opname(sr, sg, sb, sa, dr, dg, db, da); \dst[0] = IRGBA_TO_A8R8G8B8(dr, dg, db, da); \} \}

然后开始生成我们的各种合成函数：

IPIXEL_COMPOSITE_PREMUL(pre_xor, XOR);IPIXEL_COMPOSITE_PREMUL(pre_plus, PLUS);IPIXEL_COMPOSITE_PREMUL(pre_src_atop, SRC_ATOP);IPIXEL_COMPOSITE_PREMUL(pre_src_in, SRC_IN);IPIXEL_COMPOSITE_PREMUL(pre_src_out, SRC_OUT);IPIXEL_COMPOSITE_PREMUL(pre_src_over, SRC_OVER);IPIXEL_COMPOSITE_PREMUL(pre_dst_atop, DST_ATOP);IPIXEL_COMPOSITE_PREMUL(pre_dst_in, DST_IN);IPIXEL_COMPOSITE_PREMUL(pre_dst_out, DST_OUT);IPIXEL_COMPOSITE_PREMUL(pre_dst_over, DST_OVER);

这样你相当于定义了：

ipixel_comp_pre_xor (...)ipixel_comp_pre_plus (...)....ipixel_comp_dst_over (...)

等好几个函数了，并且这些函数都是被你 “组装” 出来的，你并没有使用函数指针，也没有笨重的去写20多个函数。进一步如果你写图形图像你会发现你需要面对多种设备的像素格式，从 A8R8G8B8, A8B8G8R8 到 A1R5G5B5 , 主流需要处理的像素格式都有10多种。

那么你可以把 “从不同格式读取 r,g,b,a”， 以及 “将 r,g,b,a组装成任意格式”，展开成很多个宏，然后不管你在这些像素格式里面做转换还是要做一些其他处理，你都可以用任意的 “像素读写” 宏 + “像素计算” 宏 组装成一个个具体需要的函数。

所以用宏来解决性能问题，并且简化自己的程序设计往往能起到 inline不能起的作用，甚至能完成很多 template 所不能完成的任务。

3. 数据结构和算法：

具体可以参考 Linux Kernel的 include/linux/list.h:

struct list_head {struct list_head *next, *prev;};#define INIT_LIST_HEAD(ptr) do { \(ptr)->next = (ptr); (ptr)->prev = (ptr); \} while (0)/* * Insert a new entry between two known consecutive entries.  * * This is only for internal list manipulation where we know * the prev/next entries already! */static __inline__ void __list_add(struct list_head * new,struct list_head * prev,struct list_head * next){next->prev = new;new->next = next;new->prev = prev;prev->next = new;}

这里定义了一个 LIST，kernel中，能用 inline的地方都用了，但是有些地方用不了，比如，你有一个结构体 （netfilter 部分）：

struct nf_hook_ops{struct list_head list;/* User fills in from here down. */nf_hookfn *hook;int pf;int hooknum;/* Hooks are ordered in ascending priority. */int priority;};

然后你有一个链表，记录着很多 nf_hook_ops，你取到了其中一个节点的指针，其实是指向结构体的 &list这个成员的，你需要得到对应结构体的指针，那么你可以用下面的 list 的宏：

/** * list_entry - get the struct for this entry * @ptr:the &struct list_head pointer. * @type:the type of the struct this is embedded in. * @member:the name of the list_struct within the struct. */#define list_entry(ptr, type, member) \((type *)((char *)(ptr)-(unsigned long)(&((type *)0)->member)))

比如，list_entry(ptr, struct nf_hook_ops, list) 就能根据节点指针，和在某个 struct里面的位置，取到某个节点对应的 struct的指针了。这个做法，用 inline也是没法做的。

同样的应用，在 Kernel中，还有红黑树 rbtree.h，rbtree.c中的实现，和 list很类似，大量的宏应用。Linux 用基础的宏实现的 list, rbtree等基础数据结构，用起来是相当方便的，有些地方比 std::list, std::map 都方便多了，比 STL性能高的同时，避免象模版一样为每种类型生成不同的代码，让你的二进制程序变得很臃肿。

比如你在做题的时候，用上了这样的数据结构，你程序会比用 stl容器的代码更高效和精简，同时你不知道目标平台 STL是怎么实现的，你无法控制，明明我在这个平台写着很快的代码，为何换个平台又慢了，为了追求究极性能，这样重新定义数据结构，其实是可以理解的。

4. 其他 inline 无法代替宏的地方

• 针对不同平台特性（比如整数是32还是64，lsb还是msb）写出的优化代码。
  
• 泛型的模拟
  
• 小型高频重复的代码片
  
• 硬件操作的定义

等等，很多情况，inline或者 template还是无法把宏给代替了，所以很多开源项目的代码里面，大量的出现各种宏，主要是出于这些方面的考虑。