4 ms·

> "C lacks good memory management" C lets you manage memory without possibly inefficient or even broken magical black box automated processes or garbage collec

> "C lacks good memory management" C lets you manage memory without possibly inefficient or even broken magical black box automated processes or garbage collectors. Maybe what the author meant to say was "C lacks easy memory management."

raverbashing 14y ago
Funny you mention "black box automated process" because, what do you think malloc is? There are two ways of allocating memory directly from the kernel (IIRC), brk and mmap. There's some management malloc does, and if it's good or not depends on you application. For example, size, number and behaviour of your allocations. Depending on your situation you may want to do your own memory management.
- simias 14y ago
  You're kind of reinforcing the OP's point though. C does lack easy memory management, unless you're ready to rely on external GC libraries.
- qdog 14y ago
  When I worked on embedded systems, we didn't use malloc() at all, just some heap functions. Even after that, there have been times where I worked on projects where there was a single malloc() and that was turned into a memory heap. However, a call to malloc() is pretty straightforward, you expect it to return a pointer to the allotted memory, or not. Using a GC or the boots libraries is not quite as straightforward, and the black box is a lot bigger.
CJefferson 14y ago
Consider realloc. Seems like a sensible function, with its ability to extend memory blocks in-place. Except, you can't try to extend a memory block in-place, but not move it if it can't be extended. malloc and friends really are a quite poor way of managing a memory space if you want to do even slightly clever things I find, unfortunatly
- nullc 14y ago
  There are plenty of malloc alternatives (tcmalloc,jemalloc, etc)— and yet I'm not aware of any that has bothered with a realloc_only_if_you_dont_need_to_move(). I'm not aware of any higher level language construct that reduces to that— where your program flow changes depending on details of the systems memory management. If this were an interesting case, I would have thought someone would have implemented it somewhere. Seems to me that you're making a weird strawman argument there.
  - CJefferson 14y ago
    This isn't a detail of systems memory management, this is "all my pointers just moved to a different place". You can't really get something more major! You can't use realloc on C++ types (which typically need their constructors/destructors running without their memory address moving underneath them). I've written C types which had similar behaviour, and were not happy about being moved. Of course you can (and people do) write code which will after the move go through and do fix-ups, but it is often move pleasant to do the move yourself, if an in-place move isn't going to work.
- haberman 14y ago
  The magic of C is that no one is making you use realloc() if you don't want to. realloc() is also written in C. You can write your own, and people do, all the time.
pdeuchler 14y ago
Unless you're the most complete full stack engineer ever, at some point you're going to be relying on a magic black box. The trick is to know what is acceptable as a black box or not. At this point in time, I'd say most memory management systems are pretty competent enough to warrant usage.
deleted 14y ago
[deleted]

raverbashing 14y ago

Funny you mention "black box automated process" because, what do you think malloc is? There are two ways of allocating memory directly from the kernel (IIRC), brk and mmap. There's some management malloc does, and if it's good or not depends on you application. For example, size, number and behaviour of your allocations. Depending on your situation you may want to do your own memory management.

simias 14y ago
You're kind of reinforcing the OP's point though. C does lack easy memory management, unless you're ready to rely on external GC libraries.
qdog 14y ago
When I worked on embedded systems, we didn't use malloc() at all, just some heap functions. Even after that, there have been times where I worked on projects where there was a single malloc() and that was turned into a memory heap. However, a call to malloc() is pretty straightforward, you expect it to return a pointer to the allotted memory, or not. Using a GC or the boots libraries is not quite as straightforward, and the black box is a lot bigger.

CJefferson 14y ago

Consider realloc. Seems like a sensible function, with its ability to extend memory blocks in-place. Except, you can't try to extend a memory block in-place, but not move it if it can't be extended. malloc and friends really are a quite poor way of managing a memory space if you want to do even slightly clever things I find, unfortunatly

nullc 14y ago
There are plenty of malloc alternatives (tcmalloc,jemalloc, etc)— and yet I'm not aware of any that has bothered with a realloc_only_if_you_dont_need_to_move(). I'm not aware of any higher level language construct that reduces to that— where your program flow changes depending on details of the systems memory management. If this were an interesting case, I would have thought someone would have implemented it somewhere. Seems to me that you're making a weird strawman argument there.
- CJefferson 14y ago
  This isn't a detail of systems memory management, this is "all my pointers just moved to a different place". You can't really get something more major! You can't use realloc on C++ types (which typically need their constructors/destructors running without their memory address moving underneath them). I've written C types which had similar behaviour, and were not happy about being moved. Of course you can (and people do) write code which will after the move go through and do fix-ups, but it is often move pleasant to do the move yourself, if an in-place move isn't going to work.
haberman 14y ago
The magic of C is that no one is making you use realloc() if you don't want to. realloc() is also written in C. You can write your own, and people do, all the time.

pdeuchler 14y ago

Unless you're the most complete full stack engineer ever, at some point you're going to be relying on a magic black box. The trick is to know what is acceptable as a black box or not. At this point in time, I'd say most memory management systems are pretty competent enough to warrant usage.

deleted 14y ago

[deleted]