如果这是一个坏主意,如何在函数中分配内存?
这不是一个“坏主意”,而是“有时候是一个坏主意”,可以说是编程中的许多想法。
顺便说一下,在函数内部分配内存并将其释放到外部可能是一种常见的设计模式。 考虑:
// hashtable is a typedef-ed pointer type hashtable ht = hashtable_new(); // .. do something with hashtable hashtable_free(ht);
ht
在函数hashtable_new
中分配并在其外部发布,但是你会在很多好的C代码中反复看到这种模式。
然而,它所显示的是同一逻辑单元 (散列表ADT)如何处理分配和解除分配。 这很有意义 – 因为知道如何分配的人,最了解如何解除分配。 在不同的逻辑单元中分配和释放通常是个坏主意。
如果我们改回它,这个问题最容易回答:
答案是, 没有内存泄漏或悬空指针 , 没有任何其他function的合作就可以实现这一有价值的结果。 因此,更容易获得正确的代码,并且该函数具有简单的界面。
现在,如果一个函数调用malloc
但不是free
呢? 然后必须有关于谁有义务释放内存,允许完成以及何时需要完成的规则。 这些规则成为函数接口的一部分 ,任何调用该函数的人都必须确保规则或遵循规则,或者可能对其调用者施加类似的规则,等等。 显式内存管理增加了接口的复杂性,接口越复杂,越容易导致内存错误 – 而在C中,内存错误会导致程序崩溃。
不幸的是,有时必须有一个对象(a)必须在运行时分配,(b)必须比分配它的函数的激活寿命更长。 在这种情况下,即使看起来这可能是一个坏主意,我们别无选择,只能进行分配,使接口复杂化,并要求调用者正确管理对象。
(其中一个更简单的情况是在运行时分配对象但允许永久生存。但是你必须限制这些对象的数量,否则你的空间就会用完。)
在函数中分配内存并不一定是个坏主意。 你必须确保适当地清理它。
问题是,一旦离开function范围,您可能会失去这样做的能力。
小心你的设计。 每次都免费匹配malloc,你不会有内存泄漏。
如果你只是按照自己的风格保持一致,这不是一个坏主意。
一种好的方法是将分配的内存传递给调用者,然后调用者可以在完成后释放它。 像这样的东西:
void my_new(char **obj) { *obj = malloc(somesize); }
然后从你的函数调用这个:
char *obj; my_new(&obj); /* work on obj */ free(obj)
有一些模式来管理内存:
记住一致性,否则很容易导致内存泄漏或悬空指针。
需要了解更多c/c++开发分享为什么malloc内存在一个函数中并将其释放到外面是一个坏主意?,也可以关注C/ C++技术分享栏目—计算机技术网(www.ctvol.com)!
以上就是c/c++开发分享为什么malloc内存在一个函数中并将其释放到外面是一个坏主意?相关内容,想了解更多C/C++开发(异常处理)及C/C++游戏开发关注计算机技术网(www.ctvol.com)!)。
本文来自网络收集,不代表计算机技术网立场,如涉及侵权请联系管理员删除。
ctvol管理联系方式QQ:251552304
本文章地址:https://www.ctvol.com/c-cdevelopment/980578.html