《C陷阱与缺陷》学习笔记总结：词法陷阱、语法陷阱、语义陷阱，连接、库函数、预处理器、可移植性缺陷及其他

自从上大学起，接触C也很久了，但是一直不怎么深入，也疏于练习。课程学习之余，专门的C只看过《C程序设计语言》、《C primer plus》，现在终于有了点时间看看更多的书了。本文主要记录阅读和学习《C陷阱与缺陷》的一些心得体会。

 

11月15日

前言和导读

　　“得心应手的工具在初学时的困难程度往往超过那些容易上手的工具。”比较认同这句话。我至今觉得自己其实还是个刚入了门的初学者。

 

第一章　　“词法”陷阱

 

　　由于之前学过编译原理，对编译器词法分析（主要是符号识别过程）比较了解，理解起来不困难。

　　在讲到"="和"=="、"|"和"||"、"&"和"&&"时，联想起以前见过一些程序中出现了类似于"#define ||  OR"这样的语句。当时以为可能是为了照顾习惯其他语言的使用者的阅读偏好，现在看来这样做确实可以避免一些错误。当然使用不使用这种编程风格就是另外一回事了。对于词法分析的运用到的贪心法，之前虽然知道原理和规则，但确实没有意识到这是种贪心法。这样一来，对于容易引起编译器错误的格式，写成另一种格式更好一些。

y = x/*p // 本需要进行指针取值、除法和赋值，这个颜色已表示编译器并不这么认为，因此只能写成下一种形式

y = x/(*p)

　　至于为整型常量用0补首位以便对齐，反而使得编译器将其误认为八进制数的情况倒是从来遇到也没考虑到过。

　　“单引号' '中的字符上代表一个整数，双引号" " 引起的字符串代表的是一个指向无名数组起始字符的指针。”前半句以前就知道，后半句有点意思。后半句解释了为什么char *slash = '/' 这个语句有错误。同时，书中指出整型一般为16位或32位，可以容纳多个字符（一般为8位），所以用单引号的'yes'或许能够被一些编译器正确识别，只是巧合而已。有的编译器会将'yes'多余字符忽略，只取第一个整数'y'；有的则依次取值、覆盖再取值，最后结果是只取了最后一个整数相当于's'。

 

11月16日

第二章　　“语法”陷阱

 

　　模拟调用首地址为0的子例程的语句(*(void(*)())0) ()以及它从(*fp)()生成而来的过程。把常数0转型为“指向返回值为void的函数的指针”的类型就是(void(*)()) 0，用它代替fp就生成了这个语句。使用typedef会更方便直观。根据补充阅读，在编程中使用typedef目的一般有两个，一个是给变量一个易记且意义明确的新名字，另一个是简化一些比较复杂的类型声明。前者早已知道，后者确实是个盲点，因此以前总把typedef当做另一种#define。

typedef void (*funcptr)();
(*(funcptr)0)();

利用这个特性，不难理解signal函数的声明。它接受两个参数（一个整型的信号编号和指向用户定义的信号处理函数的指针），返回值是一个指向调用前的用户信号处理函数的指针。

void (*signal(int,void(*)(int)))(int)
/*下面是简化后的函数声明*/
typedef void (*HDNDLER)(int);
HANDLER signal(int, HANDLER)

　　关于运算符优先级，以前的处理方式是无脑加括号，完全不关注；但是括号太多了确实会造成阅读困难。根据原书所示做出归纳。

+ View Code

　　多余的和缺失的分号会造成的错误一般不会出现。但是所给的例子比较醒目地提醒了结构定义后如果不加分号的结果——可能导致其后定义的函数返回类型为这种结构：

struct logrec{
......
}
main() //当然一般使用void main()

　　有时候，switch...case...结构中不一定每一个分支语句都需要break，书中字符处理的例子就不再重复。