《狂人C》阅读笔记

将在github的wiki上做持续更新,这里做个copy

https://github.com/saga/sagasw/wiki/%E7%8B%82%E4%BA%BAC

整体问题

对于C标准库的说明都说是编译器实现,这一点是不准确的,参考维基百科http://en.wikipedia.org/wiki /C_standard_library

提到一个真正是莫名其妙不知所云的C语言中国国家标准,这是个什么玩意?谭浩强主编的?

primary expression翻译成初等表达式,这个是败笔,难不成还有中等表达式和高等表达式?我建议如果再版,改做“基本表达式”,元表达式也不妥,一般来讲编程中的“元”多从“meta”这个单词产生,如metaprogramming。

page37, printf(“%d\n”, 1234567890123); // 0x11f71fb04cb 在little-endian机器上,大部分我们机器,如Intel、AMD,结果都应该是1912276171(0x71FB04CB),而在 powerpc的ibook g4 big-endian机器上,结果为287(0x11F)。这个结果是有章可循的。

page38, 应该说明sizeof不会对表达式求值。 sizeof(m++); // m will NOT increase

page62,”后者也是一种错误代码”,感觉提法不容易理解,-> “标准未定义的代码也是应该避免的”。

预处理命令 #definede : typo

注释在编译前被替换成空白字符,这部分待查(gcc,vc)。

page63,风格习惯。命名规范问题,应该用准确的英语做标记。reminder = dividend % divisor; better than ys = bcs % CS;

常见错误,/* comment */,一般常见的IDE会有代码着色功能,如VC++会把注释标记为绿色,而大部分编辑器如vim (textmate)也可以做标记着色。

《《狂人C》阅读笔记》有3个想法

  1. sizeof以及其操作数会在编译期间被替换为常数,除了C99新增的变长数组。sizeof只关心其操作数的类型,并计算其大小,并不会实际计算产生操作数的表达式。
    VC并不支持C99的VLA,即使是在GCC中使,使用VLA要格外小心。
    VLA变量只生存在栈中,默认情况下Linux下的应用程序线程栈空间有10MB,而NT下的应用程序线程栈空间只有1MB。如果是编译器自动生成数组,那么程序员便少了一次除错的机会,更糟糕的是,它可能会使BUG的现象变得诡异。应该用alloc替换VLA,当然如果程序员有绝对把握,也可以不捕获异常。

    预处理器会将每个注释块或行替换成空格。

发表评论