Structure of the second segment that is difficult to yield

The two-segment structure is also very notorious. It is not much better than MFC. It seems that there are two-segment structure everywhere in MFC. Is the reputation of the Two-segment structure also affected by MFC. After defining an object variable, you must call the Create function of the object again, and Create is successful before further operations can be performed on the object, otherwise, the object will remain invalid. This code writing method is really disgusting. Why don't you directly Create in the constructor? If the constructor fails, an exception will be thrown and the object will be aborted, better than it, it has been stuck in the world, tired and tired. In fact, there are also difficulties in selecting two segments for MFC: 1. A long time ago, the VC compiler was not very good at exception support. Of course, the VC compiler is no better than the previous one, however, it is necessary to be compatible with the previous Code; 2. Then the design of the MFC, it only makes a thin layer of packaging for the API, which means that no matter how busy, it is difficult to wrap various objects in WINDOWS into a clean C ++ object, because the API itself uses two-segment structure. Isn't it? Define a handle variable, and then CreateXXX returns the result. The returned value is invalid, indicating that the creation failed. No one knows what the consequences will be if the Overlord fails to bow.
In theory, constructor throws exceptions very elegantly, and the code is more aesthetic. In addition, the constructor performs more clearly, either simply processing the exception or waiting for the program to exit unexpectedly. However, it is quite difficult to implement exceptions. What's more, if we discard the two methods completely, in addition to exceptions, some new problems will also be introduced, which are called: "The front door drive the tiger, the back door into the wolf", not just a wolf, but several. The secret of life lies in creating new problems to solve old problems.
Directly calling Create in the constructor indicates that the user must define a type variable, and the program will immediately start the Create FUNCTION, this means that window objects, kernel objects, and even new threads may be created. These operations are not fuel-efficient lamps, and too many things are done in constructors, there may be too many details to hide. The code was originally intended to hide details. This is NOT a matter of fact. However, users cannot Say NOT to the creation process, that is to Say, if you define an object variable, you can only accept its high creation process. Is it wrong to make the object valid at the beginning? Yes. Sometimes, the user just wants to declare (define) the object first, and then let it enter the valid state when necessary (the time is ripe. Sorry, it's not good for the user to write code like this. He/she should be forced to define the object variable at that time. How can variables be defined at will? It should be defined only when it is needed. This is a good code style. However, in some cases, it is really necessary to temporarily define the object variables in an invalid state. For example, when this object is a member variable of another object (owner), there is nothing to do with it, force the user to define the owner object variable only when necessary. But what if the owner must be a global variable? That's nothing. Just define the owner as a pointer variable? Well, it's just a situation where the object fails to be created. Now we need to consider the details of the memory allocation, and then the new delete, and then the various SMART pointers are shown on stage. What's worse, the problem of invalid object validity is still not eliminated, because as long as a pointer is introduced, every time a pointer is used, it is necessary to check whether the pointer is valid or not. isn't an exception thrown when a null pointer is operated? In the C ++ specification, null pointer operations are uncertain consequences. For C ++, uncertain operations often mean the worst. In addition, since the object can only remain in the valid state, it is impossible to provide an operation that invalidates the object. If you want to invalidate an object, the only way is to let it die and force the object to start the destructor. The way is to leave the strong scope to delete it. The next time you want to use it, it will be new or defined again. No, it is another new life. However, for objects constructed by two segments, only Destroy or Create is required, and the object can always have only one. In addition, the structure of the second segment is quite scalable and can easily be constructed into three segments. Users have the right to choose each step. However, constructor exceptions do not have this advantage.
Considering the parameter issues in the constructor, for example, the month parameter, we all know that the valid value is only between 1 and 12 months. In this case, it is not discussed whether invalid parameter passing is the logic of the Code. In this case, the object under the guidance of the constructor is impossible to have a constructor without parameters (no parameters or parameters have default values). Therefore, they cannot be used in arrays, it is difficult to apply to global variables, static variables, and data members of other objects. If you have to use them in these scenarios, such as placeholders, you can only use pointers, as mentioned above, you must check the pointer validity before using the pointer, for fear that it will not be much better than checking the validity of the second segment.
The second segment structure does not easily deprive users of their rights. It provides more options for containers in arrays, stacks, and STL. If it is to die, it will die. If it is to live, it will live, however, it can never disappear. The only thing you need to do is to know whether it is a dead or live task when using it, but to make a few more judgments. In contrast, constructor exceptions are more invasive, And once used, they can only be forced to follow its rules.
In fact, the constructor and constructor of two segments are disgusting. As long as a piece of code uses it, all the Code related to it cannot get out of the way. The difference lies in who is worse than others. This is different depending on the taste of each person. For those who are afraid of allocating memory, releasing memory, and even more afraid of exceptions (this does not mean that they cannot write exceptional and secure code), of course, the second-segment structure is preferred, in terms of MORE than tive, it is claimed that, if not necessary, do not provide Default constructors to avoid objects falling into the semi-dead state. My habit is to provide the default constructor unless necessary. Do not deprive the user of the right to use the object array easily, or because the default constructor is not provided, and the resulting inconvenience.
Well, since the program decides to construct with two segments, what should we do if the user has defined an object and forgets to construct it again, but wants to execute other operations? Well, that's nothing. Since users do not comply with the contract, our objects can naturally make various uncertain behaviors. Of course, don't forget to add several assert statements to each of the other operations. Although this is disgusting, it is better than nothing to avoid guilt, so that you can find problems in the debugging version.

Author huaxiazhihuo