Comment on the quality of the MFC (3) library code

Comment on the quality of the MFC (3) library code

Keywords: C ++, MFC, rect, crect, point, cpoint, quality

Note: The program snippets only include the Code necessary for understanding, and the rest are omitted.

No one's code can completely eliminate quality risks. However, as the library code of MFC, it won't be too demanding on its quality.

1. Focus on Efficiency
File: // in <windef. h>
Typedef struct tagrect
{
Long left;
Long top;
Long right;
Long bottom;
} Rect, * prect, near * nprect, far * lprect;
File: // in <afxwin. h>
Class crect: Public tagrect
{
Cpoint & topleft ();
Cpoint & bottomright ();
};
File: // in <afxwin1.inl>
_ Afxwin_inline cpoint & crect: topleft ()
{Return * (cpoint *) This);} file: // [1]
_ Afxwin_inline cpoint & crect: bottomright ()
{Return * (cpoint *) This + 1);} file: // [2]
Topleft () provides the set and get functions by returning cpoint. In addition, the returned cpoint is more efficient than the returned cpoint. However, the implementation of functions must rely on the Cross-type conversion of pointers (that is, converting from crect * to a completely irrelevant cpoint *). In addition, it should be assumed that the compiler stores each data member in sequence. It is unsafe to convert pointer types at will. It depends on the compiler implementation and cannot be transplanted. maintainability will be reduced in future extension (such as adding data members), and errors may occur (such as when virtual functions are introduced, some compilers place virtual tables in front of the Object Storage address ).

2. Regardless of Efficiency
File: // in <afxwin. h>
Class crect: Public tagrect
{
Bool ptinrect (point) const;
};
Because the point struct is longer than the 32-bit address length and the efficiency of using the parameter value transfer is not high, it should be changed to reference.
The software design should maintain a unified trade-offs principle. If we say that we are not willing to use such extreme methods to improve efficiency in the above aspect, why should we let go of the obvious ways to improve efficiency?

3. The algorithm is not rigorous.
File: // in <afxwin. h>
Class crect: Public tagrect
{
Bool isrectempty () const;
};
The isrectempty () function returns 1 if the rectangle area is empty, and 0 if the rectangle area is not empty.
The following test code is provided:
Crect CTS (100,100 );
Bool B = RDBMS. isrectempty ();
After running, the value of B is actually 1 !?
Some crect member functions, such as intersectrect () and unionrect (), must call normalizerect () first to ensure that the correct results are obtained. However, isrectempty () does not need to depend on normalizerect (). For example, it can be implemented as follows:
Bool crect: isrectempty () const
{
Return (Left = Right & up = bottom? 1: 0 );
}
It is estimated that the implementation in MFC may be: if the right of the rectangle is <= left or bottom <= up, 1 is returned.

4. Sabotage conventional rules without reason
File: // in <afxwin. h>
Class crect: Public tagrect
{
Void operator = (const rect & srcrect );
Void operator + = (lpcrect lprect );
};
Custom types should not be worthless and incompatible with built-in types (in Objective C ++ ). Operator = () should return crect &, which also supports chained assignment. Similarly, operator + = () should also return crect &.

5. failed to guarantee security
File: // in <afxwin. h>
Class crect: Public tagrect
{
Crect operator + (lpcrect lprect) const;
};
Operator + () should return const crect. In this way, we can disable the pathological statements such as (A + B) = C;, and also maintain the same behavior as the built-in type.

6. failed to improve availability and reliability
File: // in <afxwin. h>
Class CDC: Public cobject
{
Bool bitblt (int x, int y, int nwidth, int nheight, CDC * psrcdc,
Int xsrc, int ysrc, DWORD dwrop );
};
Make a simple analogy:
File: // in <string. h>
Size_t _ cdecl strlen (const char *);
Why should the parameter be declared as const char *? Because, first, const char * can accept both constant strings and extraordinary strings, while char * can only accept extraordinary strings. Second, const can ensure that the function body does not change the contract of the original string.
Therefore, in the bitblt () Statement, the parameter psrcdc is the original device environment and will not change. It should be declared as const CDC *.

Please refer to the previous article "anti-MFC (ii) logical incompleteness"