ach*_*ora 2 c memory embedded coding-style misra
我一直在阅读C中的编码标准,并且大多数都不鼓励使用动态内存分配.但是在流行的使用中,动态内存分配会导致.这有一个可靠的原因.我问它使用的原因尽管它有它的缺点？这些是我的参考JPL标准:http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf 10的力量:http://spinroot.com/gerard/pdf/P10.pdf
嵌入式系统编程中通常禁止动态内存分配,特别是在安全关键的嵌入式软件中.安全关键软件的所有行业标准都禁止它:MISRA-C,DO178B,IEC 61508,ISO 26262等.
动态内存分配存在许多众所周知的问题:缓慢且可能不确定的访问时间,内存泄漏和堆碎片.
在任何类型的程序中都不需要这些问题.但是在PC /桌面等编程中,它们被认为是必然的恶,主要是因为主流操作系统限制了给每个进程的静态进程内存量,如果你想存储超出该数据的数据,你必须将它存储在堆.
当直到运行时才知道数据量时,使用动态内存也很方便.然而,在已知世界中没有计算机具有无限的内存,因此"我想使用完全可变数量的数据,我不知道多少"是一种无意义的论点.一个合适的软件工程师总是为最坏的情况设计.
特别是在嵌入式系统中,RAM的数量有限且错误的后果比弹出的内存不足消息框更可怕,您的程序必须具有100%的确定性行为.你无法设计诸如"这个程序在RAM耗尽之前会工作,然后就会崩溃和烧毁".您不能允许在您的铁路监控系统中存在可变"x"列车,您必须指定上限并在此之后设计系统.
因此,无论上面提到的动态内存的所有问题,您都不希望在这类系统中使用动态内存,只是因为它没有任何意义.
出于几乎相同的原因,这些系统也禁止递归.
C中的动态内存分配位于抽象数学和现实世界工程之间的模糊界限上.在数学上你说,"把这些数据放在一些内存中",实际上malloc()只是给你"一些记忆",基本上假装有无限量的内存.(并且在许多真实世界的系统上malloc()确实从未因为过度评估而失败.)
真正的工程必须面对所有资源的有限性,如果你完全知道你有可用的X内存,那么你必须计划内存的去向.这更加繁琐且具有挑战性,但如果没有其他原因,它会导致更好的代码和更好的性能,这会迫使您仔细考虑程序的数据流.
与常见的台式机相比malloc(),在相反的一端,嵌入式机器没有复杂的内存管理器,而且malloc()基本上"总是失败".如果你能够在没有它的情况下进行编程,那么你就可以为这样的平台编程.另一方面,如果您的编程风格总是假定魔术内存的无限可用性,那么您将发现在这样的平台上进行编程非常困难.