3

I have been reading coding standards in C and most of them discourages use of dynamic memory allocation.But In popular use Dynamic memory allocation leads .Any solid reason for this.I am asking the reasons for its use despite the Demerits it posses ? These are my references JPL Standards :http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf Power of 10 :http://spinroot.com/gerard/pdf/P10.pdf

achoora
  • 1,270
  • 1
  • 16
  • 32
  • 1
    Uhh... what do you mean discourage use of dynamic memory allocation. You can't control the size of objects at runtime if you don't have dynamic memory allocation. If you want an array that resizes, or a variable length list, etc., you're going to need `malloc` at some point, whether that's a direct call, or hidden by other library calls. – nchen24 Dec 09 '14 at 08:29
  • 4
    Because on some very small platforms, there is no heap. And on slightly larger platforms, you'll want very deterministic resource usage. – Oliver Charlesworth Dec 09 '14 at 08:31
  • @nchen24 the Ten Rules of Coding and JPL Coding standards prohibits the use of Dynamic memory allocation.. – achoora Dec 09 '14 at 08:33
  • Well, I missed the #embedded tag before, so my statement is not necessarily to be taken at face value. Google has lead me to a document saying: "Do not use dynamic memory allocation after task initialization." Citing: "The reason is simple: memory allocators and garbage collectors often have unpredictable behavior that can significantly impact performance." I'm not sure what GCs they are referring to, normal C has none. They go on to say that using dynamic memory leads to more errors, but I think proper defensive programming is better than a blanket "no dynamic memory" statement. – nchen24 Dec 09 '14 at 08:40
  • @nchen24 some of my peers who worked with defence also told me that they never use dynamic allocation even in RTOS based coding . – achoora Dec 09 '14 at 08:45
  • 1
    The coding standards you are referring to explicitly apply to _mission critical flight software_. This type of software aims to foresee every event that might happen, so the idea is to preallocate any memory you might need in that case. – mfro Dec 09 '14 at 08:48
  • 1
    see also here http://stackoverflow.com/questions/22146094/why-should-i-use-a-pointer-rather-than-the-object-itself – Giorgi Moniava Dec 09 '14 at 09:09
  • @giorgim I am an only C(Dunno even C++ :)) guy,Thanks for the link – achoora Dec 09 '14 at 09:16

2 Answers2

7

Dynamic memory allocation is generally banned in embedded systems programming, particularly in safety-critical embedded software. All industry standards for safety-critical software bans it: MISRA-C, DO178B, IEC 61508, ISO 26262 and so on.

There are many well-known issues with dynamic memory allocation: slow and possibly indeterministic access time, memory leaks and heap fragmentation.

None of these issues are desired in any kind of program. But in PC/desktop etc programming, they are regarded as a necessary evil, mainly because the mainstream operative systems restrict the amount of static process memory given to each process and if you want to store data beyond that, you have to store it on the heap.

It is also convenient to use dynamic memory when the amount of data isn't known until runtime. However, there exist no computer in the known world with unlimited memory, so "I want to use a completely variable amount of data, I don't know how much" is kind of a nonsense argument. A proper software engineer always designs for the worst case scenario.

Particularly in embedded systems, where the amount of RAM is limited and the consequences of bugs are far more dire than an out-of-memory message box popping up, your program must have 100% deterministic behavior. You can't design in things like "this program will work until it runs out of RAM, then it will crash and burn". You can't allow a variable "x" number of trains to exist in your railway supervisory system, you must specify the upper limit and design the system after that.

So no matter all the issues with dynamic memory mentioned above, you don't want to use dynamic memory in these kind of systems, simply because it doesn't make any sense.

Recursion is also banned from these systems, for pretty much the same reasons.

Lundin
  • 195,001
  • 40
  • 254
  • 396
5

Dynamic memory allocation in C sits on the blurry line between abstract mathematics and real-world engineering. Mathematically you say, "put this data in some memory", and indeed malloc() just gives you "some memory", basically pretending that there is an unbounded amount of memory. (And on many real-world systems malloc() does in fact never fail, due to over-comitting.)

Real engineering has to face the boundedness of all resources, and if you approach a problem knowing full well that you have X amound of memory available, then you have to plan where the memory goes. This is more cumbersome and challenging, but it can also lead to better code and better performance, if for no other reason than that it forces you to think carefully about the data flow of your program.

By contrast to common desktop machines on which malloc() never fails, there are also, at the opposite end of the spectrum, embedded machines which don't have sophisticated memory managers and on which malloc() essentially "always fails". If you are able to program without it, then you are able to program for such platforms. On the other hand, if your programming style always assumes the unlimited availability of magic memory, then you will find programming on such platforms very difficult.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • Even in desktop machines, you may want to avoid naive calls to malloc. Say, you're building a tree of million vertices, and applying malloc/free to each vertices will be a horribly inefficient program. –  Dec 09 '14 at 09:41
  • @xiver77: Right, that's why I said that thinking about the problem may result in better code :-) – Kerrek SB Dec 09 '14 at 09:56
  • @xiver77 So you mean in GPU programming also Dynamic memory allocation is discouraged ?? – achoora Dec 09 '14 at 11:22
  • @achoora I meant 'vertices' as 'nodes', 'tree' as a type of graph. –  Dec 09 '14 at 11:24
  • @xiver77 I thought about vortex and stuff like that :) – achoora Dec 09 '14 at 11:47
  • @achoora: I don't want to use the word "discouraged". You just have to be in a very different mindset depending on whether your environment can provide you with unlimited resources or whether you have to live entirely inside a space once given to you. Either way of programming can be appropriate. It depends. – Kerrek SB Dec 09 '14 at 13:24