从函式角度看 i++ 和 ++i

retuor

学了点函式编程后，回过头来看 c 语言，到处都是副作用。

不知道大家以前是怎么看待  i++ 和 ++i 的。一般书上都是先如何再如何，硬把时态附加到'数学'表达式上。我以前也是按照这种方式来理解这个表达式的。学习了副作用的观点后，对这两个表达式有了很简洁的解释：

1) i++, ++i 的副作用都是使变量 i 的值增加 1

2) 表达式 i++ 的值是 i

3) 表达式 ++i 的值是 i+1

我觉得这样解释很完美了。

赋值表达式 x=1 可以这样解释

1) x=1 的值为 1

2) 副作用为使得变量 x  的值变为 1。

区分了变量的值和表达式的值。


呵呵，是不是有点变态。

[ 本帖最后由 retuor 于 2009-3-15 11:41 编辑 ]

MMMIX

原帖由 retuor 于 2009-3-15 11:39 发表
区分了变量的值和表达式的值。


呵呵，是不是有点变态。

一点也不，如果再看点程序设计语言原理方面的书，你会发现，即使在命令式语言中，也照样是区分变量的值和表达式的值的。只不过在一般讲语言使用的书中不强调这个罢了。

retuor

说的对。但对命令式过来的人，可能会对这个有点‘异样感觉‘。

比如

printf ();

是有值的，但一般不去管它，只关心它的副作用。

在一些比较学究或严格的代码中，printf 调用被写为

(void) printf ();

这样就明确地指出了要抛弃 printf 的返回值。

MMMIX

原帖由 retuor 于 2009-3-15 13:23 发表
在一些比较学究或严格的代码中，printf 调用被写为

(void) printf ();

这样就明确地指出了要抛弃 printf 的返回值。

这不是学究，而是为了避免在某些情况下的警告，例如 lint 或者较严格的编译器检查。

flw

我认为这就学习 FP 的意义之一。
学了 Haskell 之后，再反过来看 C 语言里面的一些经典问题，会发现答案其实都是显而易见的。

ypyf3000

可爱的flw ,好讨厌你

retuor

>>这不是学究，而是为了避免在某些情况下的警告，例如 lint 或者较严格的编译器检查。

确实如此。

我觉得 lint 有点过分严格了，是个学究的检错器。

[ 本帖最后由 retuor 于 2009-3-16 20:10 编辑 ]

MMMIX

原帖由 retuor 于 2009-3-16 19:49 发表
>>这不是学究，而是为了避免在某些情况下的警告，例如 lint 或者较严格的编译器检查。

确实如此。

我觉得 lint 有点过分严格了，是个学究的检错器。

它有许多选项，好些警告都是可以有选择的关掉的。不过，那些警告往往都是不符合标准或者有潜在的问题。当然，现在的 lint 还不够智能。记得在什么地方看到过这么一句话：（大意）在 lint 警告全开的情况下，几乎不可能写出没有警告的稍微有点实用性的程序

flw

lint 代表了一些人的想法，现行的 C 编译器代表的是另一些人的想法。
曾经有人提议将 lint 继承到 gcc 内部，结果没人鸟他。
不过 gcc 现在的警告是越来越丰富了，我想最终业界会在 lint 和现行的 C 编译器之间找到一个合理的平衡点吧。
到那时候就不再需要 lint 了。