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

最新推荐文章于 2026-01-05 09:26:26 发布

转载最新推荐文章于 2026-01-05 09:26:26 发布 · 119 阅读

文章标签：

#c/c++

本文深入探讨MFC库代码中存在的六大问题，包括效率、安全性和可靠性等方面，并提供了改进意见。通过对具体函数实现的分析，指出MFC在设计时存在的不足。

非议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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10752019/viewspace-976581/