C++中的不良设计

ecai 2004-06-21 04:30:42

首先声明,起这么一个标题,目的是为了“耸人听闻”,吸引读者。:) 文中的两个函数的缺陷,不是我所发现,只是我认为很有意义,与大家共享。而且,可以了解一个成熟系统的“缺陷”,不是非常让人愉快和兴奋吗? 本文的部分内容引用了林锐的《高质量C++/C编程指南》一书。(建议大家都去读读,尤其我找工作的时候,不少小公司直接使用了书中的C++试题作为笔试题目 :) )
1: printf()相信大家都使用过,MFC 中的TRACE有同样的问题。printf()的缺陷是不安全性和不可扩展性。1)关于不安全性,《高质量C++/C编程指南》一书有明确的解释:【建议6-1-2】尽量不要使用类型和数目不确定的参数。C标准库函数printf是采用不确定参数的典型代表,其原型为:int printf(const chat *format[, argument]…);这种风格的函数在编译时丧失了严格的类型安全检查。int i;printf("%s",i); // 编译时无法使用严格的类型安全检查。
2)关于不可扩展性,是指它不可以和自定义的类型配合使用。请看以下代码:int i;float f;
CStudent student; // 自定义的类型,其中重载了 << 操作符cout << i << f << student;printf("%d %f",i,f); // 不能和student配合使用
2. getchar()函数,《高质量C++/C编程指南》一书有明确的解释 1) 【规则6-2-2】函数名字与返回值类型在语义上不可冲突。违反这条规则的典型代表是C标准库函数getchar。例如:
char c;
c = getchar();

if (c == EOF)



按照getchar名字的意思,将变量c声明为char类型是很自然的事情。但不幸的是getchar的确不是char类型,而是int类型,其原型如下: int getchar(void);
由于c是char类型,取值范围是[-128,127],如果宏EOF的值在char的取值范围之外,那么if语句将总是失败,这种“危险”人们一般哪里料得到!导致本例错误的责任并不在用户,是函数getchar误导了使用者。
2) 【规则6-2-3】不要将正常值和错误标志混在一起返回。正常值用输出参数获得,而错误标志用return语句返回。回顾上例,C标准库函数的设计者为什么要将getchar声明为令人迷糊的int类型呢?他会那么傻吗?在正常情况下,getchar的确返回单个字符。但如果getchar碰到文件结束标志或发生读错误,它必须返回一个标志EOF。为了区别于正常的字符,只好将EOF定义为负数(通常为负1)。因此函数getchar就成了int类型。我们在实际工作中,经常会碰到上述令人为难的问题。为了避免出现误解,我们应该将正常值和错误标志分开。即:正常值用输出参数获得,而错误标志用return语句返回。函数getchar可以改写成 BOOL GetChar(char *c);虽然gechar比GetChar灵活,例如 putchar(getchar()); 但是如果getchar用错了,它的灵活性又有什么用呢?
...全文
92 回复 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复

16,548

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • AIGC Browser
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧