T版继续贴啊

反正是我的主题帖  

我啥时候都能阅读

21.12 指针真得比数组快吗？函数调用会拖慢程序多少？  ++i 比 i = i +1 快吗？
这些问题的精确回答, 跟你所用的处理器和编译器有关。如果你必 须知道, 你就得小心的给程序计时。通常, 差别是很小的, 小到要经过 千万次迭代才能看到不同。如果可能, 查看编译器的汇编输出, 看看这 两种方法是否被编译的一样。
一般的机器, 通常遍历大的数组时, 用指针比用数组要快, 但是某些 处理器就相反。

函数调用, 虽然明显比内联代码要慢, 但是它对程序的模块化和 代码清晰度的贡献, 很少有好的理由来避免它。

在修整象 i = i + 1 这样的代码前, 记住你是在跟编译器 打交道, 而不是键击编程的计算器。对于 ++i,  i += 1 和 i = i + 1, 任何好的编译器都会生成 完全一样的代码。使用任何一种形式只跟风格有关, 于效率无关。 参见问题 3.10。

21.14 怎样不用临时变量而交换两个值？
一个标准而古老的汇编程序员的技巧是：
    a ^= b;
    b ^= a;
    a ^= b;

但是这样的代码在现代高级程序设计语言中没什么用处。 临时变量基本上是自由使用的, 一般上的三个赋值是:
    int t = a;
    a = b;
    b = t;

这不只对读者更清晰, 更有可能被编译器辨别出来而 变成最有效的代码 (例如有可能使用 EXCH 指令)。 后面的代码明显的可以用于指针和浮点值, 而不象  XOR 技巧只能用于整型。参见问题 3.4 和 10.2。

霸气的插楼，，

介是要加精么？

21.19 C 是个伟大的语言还是别的？哪个其它语言可以写象  a+++++b 这样的代码？
在 C 中, 写成这样也是没有意义的。词汇分析的规则规定, 在一 个简单的从左到右扫描中的每个点, 最长的记号被划分, 不管这样 出来的记号序列是否有意义。问题中的片段被解释为:
    a ++ ++ + b

语法上是个不合法的表达式。
参考资料: [K&R1, Sec. A2 p. 179]; [K&R2, Sec. A2.1 p. 192]; [ISO, Sec. 6.1]; [H&S, Sec. 2.3 pp. 19-20]。

我只挑最常遇见的问题哦

12.34 我很吃惊, ANSI 标准竟然有那么多没有定义的东西。 标准的唯一任务不就是让这些东西标准化吗？
某些构造随编译器和硬件的实现而变化, 这一直是 C 语言的一个特点。 这种有意的不严格规定可以让编译器生成效率更高的代码, 而不必让所有 程序为了不合理的情况承担额外的负担。因此, 标准只是把现存的实践 整理成文。
编程语言标准可以看作是语言使用者和编译器实现者之间的协议。协议的 一部分是编译器实现者同意提供, 用户可以使用的功能。而其它部分则包 括用户同意遵守, 编译器实现者认为会被最受的规则。只要双方都恪守 自己的保证, 程序就可以正确运行。如果任何一方违背它的诺言, 则结果 肯定失败。

参见问题 11.35。

参考资料: [Rationale, Sec. 1.1]。

没关系  这个东东不需要背诵下来  

用着的时候 来查一查 就可以了

12.35 有人说 i = i++ 的行为是未定义的, 但是我刚在一个兼容 ANSI  的编译器上测试, 得到了我希望的结果。
面对未定义行为的时候, 包括范围内的实现定义行为和未确定行为, 编译器 可以做任何实现, 其中也包括你所有期望的结果。但是依靠这个实现却不明智。 参加问题 7.4, 11.31, 11.32 和 11.34。

6.1 臭名昭著的空指针到底是什么？
语言定义中说明, 每一种指针类型都有一个特殊值 --- ``空指针" ---  它与同类型的其它所有指针值都不相同, 它 ``与任何对象或函数的指针值都不相等"。 也就是说, 取地址操作符 & 永远也不能得到空指针, 同样对 malloc() 的成功调用 也不会返回空指针, 如果失败, malloc() 的确返回空指针, 这是空指针的典型用法: 表示 ``未分配" 或者 ``尚未指向任何地方" 的指针。
空指针在概念上不同于未初始化的指针。空指针可以确保不指向任何对象或函数; 而未初始化指针则可能指向任何地方。参见问题 1.10、 7.1 和  7.26。

如上文所述, 每种指针类型都有一个空指针, 而不同类型的空指针的内部表示可能 不尽相同。尽管程序员不必知道内部值, 但编译器必须时刻明确需要那种空指针, 以便在需要的时候加以区分 (参见问题 5.2、 5.5 和   5.6)。

参考资料： [K&R1, Sec. 5.4 pp. 97-8]; [K&R2, Sec. 5.4 p. 102]; [ISO, Sec. 6.2.2.3]; [Rationale, Sec. 3.2.2.3]; [H&S, Sec. 5.3.2 pp. 121-3]。