Comment on the logical imperfection of MFC (II)

Comment on the logical imperfection of MFC (II)

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

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

1. Missing Design
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
{
Void swapleftright (); file: // [1]

Bool isrectempty () const;
Bool isrectnull () const;
Void setrectempty (); file: // [2]

Crect (int l, int T, int R, int B );
Crect (point topleft, point bottomright );
Crect (point, size); file: // [3]
Void setrect (INT X1, int Y1, int X2, int Y2 );
Void setrect (point topleft, point bottomright );
};
[1] Why does swapleftright () not provide the corresponding swaptopbottom ()?
[2] Likewise, why not setrectnull () is provided?
[3] since all three methods can construct crect objects, isn't it reasonable to expect setrect (point, size?
Adding these missing functions is just a hand-lifting task. The phrase "not small but not good" should not be left in the mouth!

2. inconsistency
File: // in <afxwin. h>
Class cpoint: Public tagpoint
{
Crect operator + (const rect * lprect) const; file: // [1]
};
Typedef const rect * lpcrect;
Class crect: Public tagrect
{
Crect operator + (lpcrect lprect) const; file: // [2]

Void operator + = (lpcrect lprect); file: // [3]
Void operator & = (const rect & rect); file: // [4]
};
Since the type definition of the lpcrect is in the middle, the parameters of [1] [2] are declared in different forms but with the same meaning.
[3] [4] is a similar operator overload, but different passing methods of form parameters are used.
Everyone can have their own code style, but they should always use a uniform style in the same file or at least in the same class!

3. Obstruction of syntax integrity
File: // in <afxwin. h>
Class crect: Public tagrect
{
Void operator = (const rect & srcrect );
};
As we all know, in C and C ++, any expression itself has a value. For example, a = 100 is an expression with a value of 100. With this logic premise, chained expressions can exist reasonably. In B = A = 100;, to be accurate, the value of expression A = 100 is assigned to B.
In the crect class, the return type of the value assignment operator is incorrectly set to void, so the value assignment expression between crect objects does not have a value, and the chain expression also fails.
The correct return type of this operator should be crect &.
Does MFC developers not read Objective C ++?

4. symmetric defects in mathematical operations
File: // in <windef. h>
Typedef struct tagpoint
{
Long X;
Long y;
} Point, * Ppoint, near * nppoint, far * lppoint;
File: // in <afxwin. h>
Class cpoint: Public tagpoint
{
Cpoint operator + (point) const;
};
The following test code is provided:
Point pt;
Cpoint PNT;
Cpoint result;
Result = PNT + PNT; file: // OK
Result = Pt + Pt; file: // Error
Result = PNT + Pt; file: // OK
Result = Pt + PNT; file: // Error
PNT + PNT is naturally no problem, Pt + Pt can barely understand the error, but PNT + Pt can, but Pt + PNT can not. Intuitively, addition should satisfy the exchange rate, but MFC breaks our mindset in an astonishing way.
In fact, if you declare the operator function:
Friend const cpoint operator + (const point & PNTL, const point & PNTR );
All the preceding four statements can be passed.
Some people may say: "The friend keyword is not object-oriented, so it is best not to use it ." So, I would like to say: first of all, C ++ is not Java. Its main design principle is to meet the efficiency, elasticity, and maintainability of large systems. Good object-oriented methods should be adopted, non-object-oriented methods should also be adopted. Secondly, MFC uses friend elsewhere.
If the sum of PNT and PT is not allowed, the operator function should also be declared as a safer form:
Const cpoint operator + (const cpoint & PNTR) const;
In this way, only PNT and PNT can be added.
You can do whatever you want. If you want to do it, you cannot do it. Do not discriminate!

Please refer to the next article "anti-quality issues of the MFC (3) library code"