Ｃ语言漫谈(2)

有必要在这里把其他答案为什么不能选的理由说一下。 (a) if (!pParam)
return 0;
这是很多初级程序员常常采取的一种方式。返回值设为0。 因为函数的返回值往往是计算的结果，不赞成把错误标志值和计算结果混在一起使用，容易造成使用者的误会。当然，在很多unix函数中，由于历史原因，还存在很多这样子的函数，所以需要指出，不要沿用这种方式。

(b) if (!pParam)
return ERROR_PARAM;
b比a稍微好一点点，返回了一个常量或者预定义的宏。 从返回值的字面上，调用者能知道发生了什么错误，但是，这也不是一种好的方法。

(c) if (!pParam)
pParam = “”;
…
这是最不好的方式。直接给pParam赋予空字符串，然后继续函数过程，这容易造成不可预料的后果，是程序不稳定的根源。

(d) if (!pParam)
throw EXCEPTION_ERROR_PARAM;抛出异常，刚刚已经讨论过了，不再赘述。

(e) if (!pParam)
MessageBox(…);
这是一种比较可笑的方式，当然也有不少人用。MessageBox是直接弹出一个对话框，告诉使用者，出错了。但是并不做任何处理，程序继续往下执行，直到出错崩溃。呵呵

(f) assert(!pParam);
断言，刚刚已经讨论过了，不再赘述。

以上这个题目，引发了所有与会者的兴趣，讨论异常热烈，最后，主持人也给出了自己的观点:d+f。当然这并不是标准答案，因为编程这一门课程本来就没有什么标准答案，大家见仁见智，这个答案只是经验的积累。

主持人紧接着列出了”编写优质无错代码的经验”:
a.理想的编译器和实际的编译器
b.使用断言
c.函数的界面设计
d.考虑风险
e.态度的问题

以上是本节的主要内容。断言，刚刚的问题中已经讨论过了，来看看其他的内容。

理想的编译器和实际的编译器:

题目二：
下面memcpy函数实现有什么问题：
Void *memcpy(void *pvTo,void *pvFrom,size_t size){
byte *pbTo=(byte *) pvTo;
byte *pbFrom=(byte *)pvFrom；
while(size — >0)；
*pbTo++= *pbFrom++;
return pvTo;
}

呵呵，粗略一看，这函数还真找不出问题来。但是仔细看看，你就会发现while(size — >0)；这里多了一个分号，导致下面的*pbTo++= *pbFrom++;不是在while循环中执行多次，而是只执行了一次。当然这不是函数设计者的预期结果，而编译器却不会报告错误，因为while(size — >0)；从语法上来讲，并没有错误。这就是理想的编译器和实际的编译器的区别所在。

那么，该怎么检查这种错误呢？主持人提出了如下办法：
while(size — >0) NULL; 可以加入NULL来解决空语句. 这样子，当你需
要 while(size — >0)
*pbTo++= *pbFrom++;
这种形式的时候，就不会发生错误了，只需要用眼睛看看，就能发现了。
两点好处 1 无冗余代码，2 使人更明白。减少风险.

还有人会这么写
if( (n=read(….)) == 1) ….
在这里，赋值符号=和判断相等的符号==容易敲错，而编译器又检查不出来，可能就会有如下错误：
If(ch = ‘ ’)…；这也是需要注意的问题。

理想的编译器和实际的编译器小结：
a.把屡次出错的合法的C习惯用法看成程序中的错误
b.增强编译器的警告级别
c.使用其它的工具来检查代码 如 Lint 等
d.进行单元测试
e.消除程序错误的最好方法是尽可能早、尽可能容易地发现错误，要寻求费力最小的自动查错的方法
f.努力减少程序员查错所需的技巧

使用断言
题目三
下面函数实现，哪一个好，为什么？
a.
char Uptolower(char ch){
if(ch >= ‘A’ && ch <= ‘Z’)
return ch+=‘a’-’A’;
return -1;
}
b.
char Uptolower(char ch){
assert(ch >= ‘A’ && ch <= ‘Z’)；
if(ch >= ‘A’ && ch <= ‘Z’)
return ch+=‘a’-’A’;
return ch;
}
c.
char Uptolower(char ch){
assert(ch >= ‘A’ && ch <= ‘Z’)；
return ch+(‘a’-’A’);
}
分析：
a.该函数检查ch是否在A..Z之间，如果是，则返回相应的小写字符，如果

不是，则返回-1。
缺点在于：把错误标志值和计算结果混在一起使用，容易造成使用者的误会。

b.该函数使用了断言，如果ch在A..Z之间则返回相应的小写字符，如果不是，断言会起作用，程序发生错误并退出。而最后一个return ch;则是在release的时候，如果不是A..Z之间，则返回原来的字符。但是，从书写效率上来说，这个函数稍微罗嗦了一点。因为它重复使用了断言和if判断。

c.该函数也使用了断言，返回相应大写字母的小写字母。

使用断言的好处：
a.暴露了调用者的错误
b.便于调试
c.对代码没有代价
d.最少的处理代价

断言使用举例：
void memcpy(void * pvTo,void *pvFrom,size_t size){
void *pbTo= (byte *)pvTo;
void *pbFrom= (byte * pvFrom);
assert(pvTo !=NULL && pvFrom !=NULL);
assert(pbTo >= pbFrom +size’ ‘pbFrom >= pbTo+size);
…
}

使用断言的规则：
a.要使用断言对函数参数进行确认
b.要从程序中删去无定义的特性或者在程序中使 用断言来检查出无定义特性的非法使用
c.不要浪费别人的时间-详细说明不清楚的断言
d.消除所做的隐式假定，或者利用检查其正确性
e.在进行防错性程序设计时，不要隐瞒错误防错性程序设计虽然被誉为有较好的编码风格，但它却隐瞒了错误。要记住，我们正在谈论的错误决不应该再发生，而对这些错所进行的安全处理
又编写无错代码变得更加困难
f.要利用不同的算法对程序的结果进行确认
g.不要等待错误发生，要使用初始检查程序

断言小结：
a.要同时维护交付和调试两个版本。封装交付的版本，应尽可能地使用调试版本进行自动查错。
b.断言是进行调试检查的简单方法。要使用断言捕捉不应该发生的非法情况。不要混淆非法情况与错误情况之间的区别，后者是在最终产品中必须处理的。
c.使用断言对函数的参数进行确认，并且在程序员使用了无定义的特性时向程序员报警。涵数定义得越严格，确认其参数就越容易。
d.防错性程序设计会隐瞒错误。在进行防错编码时，如果”不可能发生”的情况确实发生了，要使用断言进行报警。

写到这里，我们初步探讨了编写优质无错代码的必要性，原则，和相关经验。留几个练习题目，大家也参与一下讨论吧。
练习题目1:
下面的memset函数实现有什么问题？

void *memset(void *pv, byte b, size_t size)
{
byte *pb = (byte *)pv;
unsigned long l;
size_t sizeSize;

l = (b << | b; /* 用4个字节拼成一个long */
l = (l << 16) | l;
pb = (byte *)longfill((long *)pb, l, size/4);
size = size % 4;

while (size– > 0)
*pb++ = b;
return (pv);
}

练习题目2:

下面的代码用memset将三个局部变量置为0，请问可能会有什么问题？
void DoSomeThing(…)
{
int i;
int j;
int k;

memset(&k, 0, 3*sizeof(int)); // 将i,j,k置为0
…
}

练习题目3:

定义结构如下：
typedef struct
{
char c1;
char c2;
int n;
} stru;
请问sizeof(stru)等于多少？并说明理由。

练习题目4:

下面是C语言中两种if语句判断方式。请问哪种写法更好？为什么？
int n;

if (n == 10) // 第一种判断方式
if (10 == n) // 第二种判断方式

练习题目5:

下面的代码有什么问题？
void DoSomeThing(…)
{
char* p;
…
p = malloc(1024); // 分配1K的空间
if (NULL == p)
return;
…
p = realloc(p, 2048); // 空间不够，重新分配到2K
if (NULL == p)
return;
…
}

练习题目6:

下面的代码有什么问题？
char *DoSomeThing(…)
{
char str[16];

…
return str;
}

练习题目7:
下面的代码有什么问题？

char *_strdup( const char *strSource )
{
static char str[MAX_STR_LEN];

strcpy(str, strSource);
return str;
}

练习题目8:

下面的代码有什么问题？并请给出正确