科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道基础软件WINX窗口类对象的内存管理

WINX窗口类对象的内存管理

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

gc allocator比较适合作为完整应用的解决方案。但是winx只是界面库,由于库的特殊性,它的内存管理也存在一定的特殊性。

作者: 许式伟 来源:CSDN 2008年1月23日

关键字: 内存管理 窗口类 WINX Linux

  • 评论
  • 分享微博
  • 分享邮件
为了引入WINX窗口类对象的内存管理(生命周期模型),我绕了一大圈子。实在是,内存管理太重要了,花多少口舌介绍它都不过分。我曾经见到这样一句话:"C++程序员觉得内存管理太重要了,所以一定要自己进行管理;Java/C#程序员觉得内存管理太重要了,所以一定不能自己去管理"。从某种意义上说,两者都是对的。
 
我在《C++内存管理变革》系列中提到,我希望C++程序员理解allocator,并且采用gc allocator(是STL中allocator的延伸),详细参考前文:
那么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++实现的窗口类实例)的关系是奇妙的。从宏观角度讲,窗口与窗口对象的生命周期是应该是一样的。但是既然它们是两个不同的实例,当然它们的销毁仍然会有细节上的先后之分。在实际应用中,区分为两种完全不同的用况:
  1. 窗口在生成后new出窗口对象(时机一般选择在WM_NCCREATE),并成为窗口对象的Owner。这种用况只有winx支持。它的好处是:
    • 窗口对象的生命周期非常清晰,用户根本无需担心可能发生内存泄漏问题。
    • 支持可视化的自定义窗口的创建方式。详细参考:《WINX如何做到可视化界面开发》。
       
  2. 窗口对象先于窗口生成,其生命周期完全脱离窗口的生命周期。这是多数界面库的做法。WINX也支持此用法,只要你的窗口类定义了WINX_STACK_OBJECT(TRUE)。它的好处是:
    • 窗口对象可在构造时获得初始化参数,而不需要用丑陋的CreateWindow/CreateWindowEx的额外参数。
    • 对于一个模态过程(例如对话框),窗口对象还可以记录一些返回数据(退出状态)。

如何选择?

在WINX中,方式1.作为默认选择,一般的窗体遵循此模式。而所有顶级窗体(如模态对话框ModalDialog、主窗体MainFrame,MDIMainFrame等)则默认采用方式2.进行管理。我们把这类窗体声明为WINX_STACK_OBJECT,只是因为它们通常声明为栈对象(StackObject),但真实的含义是,窗口对象的生命期脱离窗口,完全由用户自己负责。


查看本文来源
    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章