WINX窗口类工具的内存打点

为了引入WINX窗口类工具的内存打点（生命周期模子），我绕了一大圈子。实在是，内存 打点太重要了，花几多口舌先容它都不外分。我曾经见到这样一句话："C++措施员以为 内存打点太重要了，所以必然要本身举办打点；Java/C#措施员以为内存打点太重要了，所以 必然不能本身去打点"。从某种意义上说，两者都是对的。

那么WINX的窗口工具是否也是回收gc allocator呢？

答：不是。

详细问题详细阐明。在凡是环境下，我小我私家确实已经很是习惯利用gc allocator来举办内 存打点，可是WINX窗口工具恰恰是个破例。为什么？原因有二：

gc allocator较量适相助为完整应用的办理方案。可是winx只是界面库，由于库的非凡性 ，它的内存打点也存在必然的非凡性。尽量我喜欢gc allocator，可是我并不能假设所有 winx的用户都喜欢gc allocator。

winx窗口工具有越发符合且极其简朴的内存打点模子。gc和gc allocator的见识，最重要 的一点，是要在任意巨大的景象下，提供办理方案来减轻利用者的内存打点承担，它们是从 更一般化的角度接头的方案。但其实智慧的开拓人员早已经发现了一种简朴有效的手工内存 打点法例：基于Owner的内存打点模子。

这种基于Owner的内存打点模子见识很是简朴：当一个工具（Child工具）被另一个工具（ Owner工具）所拥有，意味着Child工具的生命周期不行能高出Owner工具。因此，Owner工具 在自身销毁时，会认真将所有Child工具销毁。

在界面编程中，窗口（指HWND所指代的系统资源）与窗口工具（指C++实现的窗口类实例 ）的干系是奇妙的。从宏观角度讲，窗口与窗口工具的生命周期是应该是一样的。可是既然 它们是两个差异的实例，虽然它们的销毁仍然会有细节上的先后之分。在实际应用中，区分 为两种完全差异的用况：

窗口在生成后new出窗口工具（机缘一般选择在WM_NCCREATE），并成为窗口工具的Owner 。这种用况只有winx支持。它的长处是：

窗口工具的生命周期很是清晰，用户基础无需担忧大概产生内存泄漏问题。

支持可视化的自界说窗口的建设方法。具体参考：《WINX如何做到可视化界面开拓》： http://blog.csdn.net/xushiweizh/archive/2006/11/10/1378242.aspx。

窗口工具先于窗口生成，其生命周期完全离开窗口的生命周期。这是大都界面库的做法。 WINX也支持此用法，只要你的窗口类界说了WINX_STACK_OBJECT(TRUE)。它的长处是：

窗口工具可在结构时得到初始化参数，而不需要用丑恶的CreateWindow/CreateWindowEx 的特别参数。

对付一个模态进程（譬喻对话框），窗口工具还可以记录一些返回数据（退出状态）。

如何选择？

在WINX中，方法1.作为默认选择，一般的窗体遵循此模式。而所有顶级窗体（如模态对话 框ModalDialog、主窗体MainFrame，MDIMainFrame等）则默认回收方法2.举办打点。我们把 这类窗体声明为WINX_STACK_OBJECT，只是因为它们凡是声明为栈工具（StackObject），但 真实的寄义是，窗口工具的生命期离开窗口，完全由用户本身认真。