程序退出时还会有内存泄露吗？这好像是被很多人讨论过的话题了，就是用new分配的内存如果在程序退出时不释放
程序退出时还会有内存泄露吗？
这好像是被很多人讨论过的话题了，就是用new分配的内存如果在程序退出时不释放，会不会引起内存泄露？GlobalAlloc应该是会的，这个没有疑问。new 按操作系统的介绍，32位Windows应该是不会了吧？从会写程序的时候起，VC的集成环境就在程序退出时报告内存泄露，我们也习惯于努力定位解决它们，但是现在是不是真的有必要呢，谁来个令人信服的回答？
[解决办法]
程序退出了！差不多所有的资源都会释放的，被系统回收重新利用的！所以不会有内存泄漏这一说！
内存泄漏：在当前进程在堆中分配了空间后，没有及时释放掉(不再需要此空间),并且进程没有结束！
至于你说的关闭程序时提示，可能是析构函数写的有问题吧！
[解决办法]
vc 是 vc，系统是系统。
vc 跟你说有泄漏是提醒你自己收拾自己的烂摊子，别指着别人帮忙。
系统帮你收拾是系统人好，愿意多管闲事，也为系统其他程序创造良好的运行环境。
好的习惯是用 raii 管理各种资源。
一旦养成不良习惯，早晚会出问题，因为系统不能够处理所有的烂摊子。
比如我以前给 houdini 写 gpu 的 renderer，houdini 关闭的时候为了省时间，不调用我的析构函数，他们以为最差的也就是内存泄漏，然后有系统收摊呢，所以实际上没问题，这种假设对一般的 cpu 内存管用，问题是 gpu 上根本没系统，结果就出毛病了，一关闭 houdini 就挂。
总之一句话，做好自己份内的事儿。
[解决办法]
退出时 有泄漏 其实和运行时有泄漏没啥区别吧！
但程序都退出了 系统当然自己帮资源回收了 不然的话 多搞几个非正常退出程序 那么系统不就没资源可用了！
[解决办法]
通常不会。操作系统的内存分配和一个进程的内存分配是两个层次。进程的内存泄露只是在进程层次的，操作系统总是知道进程开了哪些内存。当进程结束的时候，全部都会被操作系统收回去，进程层面有没有泄露无所谓。
除非操作系统的内存分配逻辑有bug。
[解决办法]
不会，用GlobalAlloc分配的内存在程序结束（不管是正常结束还是强制终止）时也会被操作系统回收，实际上在win32/win64系统中并没有全局堆和局部堆的区别，那是win16时代的概念。
[解决办法]
要是你能让系统内存泄露，只能说明这个系统本身有问题。
程序退出，系统给这个程序的内存都会收回来。泄露是当前进程没法收回来这些内存了，但是操作系统是可以回收的。
[解决办法]
这个你就不用操心啦。
当程序退出之后，进程的空间全部都会被操作系统回收的。即使那些资源你并没有释放。
[解决办法]
为什么会提示这个, 那是因为系统也不知道你这个是在程序中只申请了一次还是会申请多次, 它没法知道. 所以只会提醒你, 从程序运行到结束, 有哪些地方内存泄漏了.
如果是多次申请的, 那么你程序使用过程只就可能随运行时间越来越长,而导致内存耗尽.
所以系统只要发现有内存泄漏就会提示, 但程序结束肯定会回收.
如果不提示你, 你何从发现是否有内存泄漏呢, 你可能运行时只看到内存一直涨, 但就是不知道为什么, 你更想看到哪种情况呢?
如果不想回收, 那就只有去使用java这类的语言了, 只要new即可, 其它什么都不用管.
[解决办法]
不会泄露
除非你申请的资源是共享的，并且有人在使用，这类东西不会释放
[解决办法]
程序都退出了，地址空间都被没了，哪还占用什么资源，皮之不存毛将焉附！！！
[解决办法]
退出的时候的确可以不这样干，但很多时候是出于习惯，当然你说的多线程也有考虑的必要。
不过这种权利仅限在退出的时候，但是新手随意的将这种有限的权利扩大化就不是好事了。
[解决办法]
GDI对象泄漏的可能性很大
[解决办法]这个不必上纲上线，对于需要长时间运行进程，累积性内存泄露十分可怕，对于生存期非常短的进程（比如编译器、连接器），有时候为了追求效率可以在进程退出时不释放内存。这里只是指进程内存，其它资源不一定适用。
[解决办法]这不是必要不必要的问题，而是有没有养成良好编程习惯问题。
不可能，你写的每一份代码，都是一个独立的程序；
很多时候，你可能只会写整个程序的一小部分，甚至是库代码的一小部分。
这时候，没有可能等到程序退出，才来解决内存泄露问题。
你必须保证，你的代码，不会有内存泄露问题。
而不是依靠，某种平台的某些特殊特性来保证。
包括内存泄露在内，的资源泄露问题，导致Win98 一直是个不稳定的系统。
经常会死机，会蓝屏。
内存泄露，资源泄露，对于长期运行的程序，影响非常大；
一个会造成包括内存泄露在内，的资源泄露问题的程序，软件，是不可能长期稳定的运行的。
如果认为小程序，不需要处理内存泄露，资源泄露。
那么，写一个很小的程序，都会存在内存泄露，资源泄露的人。
如何保证，写大程序，参与大项目，写的代码中，没有内存泄露，资源泄露。
难道，从来就只写，main 函数内部的，那一部分代码？？？？？
[解决办法]现实生活不是教科书，社会跟学校也有区别。
如果你确定的知道你在做什么，会造成什么后果，那么就让那些教条都随风去吧。
PS: 绝大部分人只怕有生以来也没有、以后也不会接触到不含有进程内存自动释放的操作系统（只要它支持进程概念），对于操作系统的内存管理来讲，这个是最基本的。除非是不支持进程概念的操作系统，不在讨论范围内（往往这样的系统中，程序退出意味着系统的关闭，自然没有什么内存泄露）。
PS2: 拿写小程序习惯推论写大程序的结果，无异于拿芝麻的标准来衡量西瓜。一、二、三，几我就用几个横写，难道你就推论‘万’我要用一万横写？
[解决办法]不会泄露的，楼主不必担心
[解决办法]我也觉得应该不会
[解决办法]对不需要长时间运行的程序，比如IE，来说，内存泄漏可能并不是什么大不了的问题，出问题了，关了再重新打开就是了。
但是对需要长时间运行的程序，比如银行系统，内存泄漏就是一种灾难了，哪怕每次泄露几个字节，时间长了也会耗尽系统内存，你说需不需要修复？
[解决办法]习惯养成以后，你就不会再区分，大程序，小程序；
何况，即便是小程序，也不一定只有自己一个人写。
小程序，养成良好习惯，大程序，就不会犯一些简单的错误。
何必为了，一个不良习惯；
去区分，何时可以放纵一点，何时可以严谨一点。
[解决办法]举个简单的例子，我们知道，程序是需要测试的。
那么，许多人一起写的程序，难道必须要等程序完工，才测试？
显然是不必的。
那么，对于局部性质的代码，你可以写个小程序测试一下。
如果你没有考虑，内存泄漏，准备让系统帮你回收内存。
那么除了内存泄漏，其他一切正常，你是不是也认为你的代码没有问题？？？？？
