Memory management of Winx window class objects

In order to introduce the memory management (lifecycle model) of the Winx window class object, I circled a large circle. Indeed, memory management is so important that it's not too much to spend a lot of time talking about it. I once saw this sentence: "C + + programmers think that memory management is too important, so be sure to manage; java/c# programmers think that memory management is too important, so it must not be managed by themselves." In a sense, both are right.

So does the Winx window object also use GC allocator?

Answer: No.

Specific analysis of specific problems. In general, I am personally very accustomed to using GC allocator for memory management, but the Winx window object is an exception. Why? There are two reasons:

GC allocator is more suitable as a complete application solution. But Winx is only the interface library, because of the particularity of the library, its memory management also exists certain particularity. Although I like GC allocator, I can't assume that all Winx users like GC allocator.

The Winx Window object has a more appropriate and extremely simple memory management model. The idea of GC and GC allocator, most importantly, is to provide solutions to mitigate the user's memory management burden in any complex scenario, and they are discussed from a more generalized perspective. But smart developers have already developed a simple and effective manual memory management rule: A memory management model based on owner.

The concept of the owner-based memory management model is simple: When an object (a child object) is owned by another object (the owner object), it means that the child object's life cycle cannot exceed the owner object. Therefore, when the owner object destroys itself, it is responsible for destroying all child objects.

In interface programming, the relationship between a window (the system resource that the HWND refers to) and a Window object (the instance of a window class implemented by C + +) is wonderful. From a macro point of view, the window and window object life cycle should be the same. But since they are two different instances, of course their destruction will still be in detail. In practical applications, the area is divided into two completely different conditions:

The window creates a new Window object after it is generated (the timing is generally selected in wm_nccreate) and becomes owner of the Window object. This condition is only supported by Winx. The benefits of this are:

The life cycle of a Window object is very clear and the user does not have to worry about possible memory leaks.

Supports the way a visual custom window is created. Detailed reference: "Winx how to achieve the visualization of the interface development": Http://blog.csdn.net/xushiweizh/archive/2006/11/10/1378242.aspx.

The Window object is generated before the window, and its lifecycle is completely detached from the window's lifecycle. This is the practice of most interface libraries. Winx also supports this usage, as long as your window class defines Winx_stack_object (TRUE). The benefits of this are:

Window objects can get initialization parameters at construction time without the need for an ugly Createwindow/createwindowex extra parameter.

For a modal procedure (such as a dialog box), the Window object can also record some returned data (the exit State).

How to choose?

In Winx, Mode 1. As the default selection, the general form follows this pattern. All top-level forms, such as modal dialog modaldialog, main form mainframe,mdimainframe, and so on, are adopted by default mode 2. For management. We declare these forms as winx_stack_object simply because they are often declared as stack objects (Stackobject), but the real meaning is that the Window object's lifetime is disconnected from the window and is entirely the responsibility of the user.