深入探索 C/C++ 数组与指针的奥秘之四：[]运算符的本质

深入探索 C/C++ 数组与指针的奥秘之四：[] 运算符的本质

下标运算符[]一直被作为数组的专有运算符来介绍，经过长年的应用，人们也早已对这个用法习以为常，视为跟每天的午餐一样稀松平常的事情。当你很遐意地写下a[0]表达式的时候，如果抽空回过头来看看标准中关于下标运算符的条款，你很可能会大吃一惊：
6.5.2.1 Array subscripting
Constraints
One of the expressions shall have type ‘‘pointer to object type’’, the other expression shall have integer type, and the result has type ‘‘type’’.
其中一个表达式具有指针类型，而不是数组类型！为什么会这样呢？如果规定为数组类型，由于表达式中的数组类型会隐式转换为指针类型，两个条款就会产生矛盾，当然，可以将下标运算符也作为转换规则的例外，但直接规定为指针类型显然能带来更多的好处，而且，既然数组类型能够转换为指针类型，却不让指针使用下标运算符，会显得无可理喻。从条款的角度来讲，下标运算符其实是指针运算符。
另一个表达式的类型是 integer，这意味着表达式的值可以是负数，这是由于指针运算里包含了减法的缘故，但是要注意不应该发生越界的行为。
在条款的上下文中，并没有规定[]运算符两个操作数的顺序，这意味着即使调换两个操作数的位置，也没有违反标准。这现象还可以从另一个角度进行分析，在表达式中，D[N] 会转换为等价表达式 *( D + N )，把 D 和 N 的位置调换，就成了 *( N + D )，就是 N[D] 了。
考虑如下代码：

int a[10]，*p = a;

p[0] = 10;

( p + 1 )[0] = 20;

0[p + 1] = 10;

( &a )[0][0] = 20;

0[&a][0] = 30;

0[0[&a]] = 40;

a[0] = “0123456789ABCDEF”[0];

下面对各个表达式进行解释：
p[0]：就是 a[0]；
( p + 1 )[0]：p 移动一个 int 的距离，就是 a[1]；
0[p + 1]：就是 ( p + 1 )[0]；
( &a )[0][0]：这个表达式有点古怪，a 的类型是 int[10]，&a 就是 int( * )[10]，是一个指向具有 10 个 int 元素的一维数组的指针，( &a )[0] 就是 &a 指向的第 0 个元素，类型为 int[10]，因此 ( &a )[0][0] 就是 ( &a )[0] 的第 0 个元素。
0[&a][0]：把 ( &a )[0][0] 第一维的 0 与 &a 调换一下，就是 0[&a][0]；
0[0[&a]]：再调换 0[&a] 与第二维 [0] 中的 0，就成了 0[0[&a]]，跟 ( &a )[0][0] 等价。
最后一个表达式 ”0123456789ABCDEF”[0] 是一个常用的技巧，它可以快速将一个数字转换为 16 进制字符。“0123456789ABCDEF” 是一个字符串字面量，类型是 char[17]（在 C 中）或者 const char[17]（在 C++ 中），转换后的指针类型分别为 char* 和 const char*，因此 ”0123456789ABCDEF”[0] 就是第 0 个元素 ’0’。这个技巧常常用在进制转换中，以下代码将一个长整数的内存映像转换为 16 进制表示：

char* convert( unsigned long Value )

{

       static char Buffer[sizeof( unsigned long ) * 2 + 1];

       int i;

       for( i = sizeof( unsigned long ) * 2 - 1; i >= 0; --i )

       {

              Buffer[i] = "0123456789ABCDEF"[Value % 16];

              Value /= 16;

       }

       return Buffer;

}

当然，笔者在这里介绍这些古怪的表达式仅仅为了对下标运算符进行一些探讨，并非鼓励人们编写这样的代码。但在某些情况下，形如 "0123456789ABCDEF"[Value%16] 这样的表达式仍然是一个很好的选择，与下面的代码相比：
前者显然更加简明、精练，更容易阅读，所以，应根据不同的情况进行取舍。代码中使用了除法和求余运算，有些人很喜欢把这些运算直接用移位代替，以追求极速。但现代编译器对代码的优化已经非常出色，乘除运算与直接移位之间的效率差别已经小到几乎可以忽略不计的程度，除非在需要进行大量数学运算或对效率极其敏感的场合，否则所提高的那么一点微末的速度是无法弥补可读性的损失的。在可读性、空间及效率之间应进行均衡的选择，而不是盲目追求极端。
原文链接：http://blog.csdn.net/supermegaboy/archive/2009/11/23/4855000.aspx。