ITPub博客

首页 > 应用开发 > IT综合 > 非议MFC(三)库代码的质量问题 (转)

非议MFC(三)库代码的质量问题 (转)

原创 IT综合 作者:amyz 时间:2007-10-14 15:15:36 0 删除 编辑
非议MFC(三)库代码的质量问题 (转)[@more@]

  非议MFC(三)库代码的质量问题

关键字:C++,MFC,RECT,CRect,POINT,CPoint,质量

说明:程序片断仅包括理解所必需的代码,其余省略。

每个人的代码都不可能完全排除质量隐患,但MFC作为库代码,对其质量怎么苛求都不会过分。

1.只顾效率
file://in
typedef struct tagRECT
{
  LONG left;
  LONG top;
  LONG right;
  LONG bottom;
} RECT, *PRECT, NEAR *NPRECT, FAR *LPRECT;
file://in
class CRect : public tagRECT
{
  CPoint& TopLeft();
  CPoint& BottomRight();
};
file://in
_AFXWIN_INLINE CPoint& CRect::TopLeft()
  { return *((CPoint*)this); }  file://[1]
_AFXWIN_INLINE CPoint& CRect::BottomRight()
  { return *((CPoint*)this+1); }  file://[2]
TopLeft()通过返回CPoint &同时提供Set和Get功能,并且,返回CPoint &比返回CPoint效率高。但是,函数的实现必须依赖指针的跨越性转换(即从CRect *转换成完全不相干的CPoint *),另外,还要假设编译器是顺序存放各数据成员。随意转换指针类型,不安全;依赖编译器实现,不可移植;以后扩展时可维护性降低(如增加数据成员),还有可能导致错误(如引入虚函数时,有的编译器将虚表放在对象存储地址的前部)。

2.不顾效率
file://in
class CRect : public tagRECT
{
  BOOL PtInRect(POINT point) const;
};
因为POINT结构体大于32位地址长度,形参使用值传递效率不高,应该改为引用。
软件的设计应该保持统一的取舍原则,如果说在上一点中,不惜采用那么极端的方式来提高效率,那么这里明显可以合理提高效率的地方为什么要放过呢?

3.算法不严谨
file://in
class CRect : public tagRECT
{
  BOOL IsRectEmpty() const;
};
IsRectEmpty()函数的功能是当矩形面积为空时返回1;当矩形面积为不空时返回0。
给出如下测试代码:
CRect rct(100,100,0,0);
BOOL b=rct.IsRectEmpty();
运行后b的值居然是1!?
有些CRect的成员函数如:IntersectRect()、UnionRect()等只有先调用NormalizeRect()才能确保获得正确结果。但IsRectEmpty()完全没必要依赖NormalizeRect(),例如可以这样实现:
BOOL CRect::IsRectEmpty() const
{
  return (left==right&&up==bottom ? 1 : 0);
}
推测起来,MFC中的实现可能是:若矩形的right<=left或bottom<=up则返回1。

4.无故破坏约定俗成的规则
file://in
class CRect : public tagRECT
{
  void operator=(const RECT& srcRect);
  void operator+=(LPCRECT lpRect);
};
自定义类型不要毫无价值的与内建类型不兼容(《Effective C++》语)。operator=()应该返回CRect &,这样做还可以支持链式赋值。同理operator+=()也应该返回CRect &。

5.没有尽力保证安全性
file://in
class CRect : public tagRECT
{
  CRect operator+(LPCRECT lpRect) const;
};
operator+()应该返回const CRect,这样做可以禁止形如(a+b)=c;的病态语句,同时也保持了与内建类型的行为一致。

6.没有尽力提高可用性和可靠性
file://in
class CDC : public Cobject
{
  BOOL BitBlt(int x, int y, int nWidth, int nHeight, CDC* pSrcDC,
  int xSrc, int ySrc, Dword dwRop);
};
做个简单的类比:
file://in
size_t  __cdecl strlen(const char *);
形参为什么要声明为const char *?因为,其一,const char *既可以接受常量字符串又可以接受非常量字符串,而char *只能接受非常量字符串。其二,const可以保证函数体不更改原字符串这一契约。
所以BitBlt()的声明中,参数pSrcDC是原设备环境,不会改变,应该声明为const CDC *。


请参考上一篇《非议MFC(二)逻辑上的不完备》


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10752019/viewspace-976581/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
  • 博文量
    3984
  • 访问量
    7335173