I'll give one for old-school: heap fragmentation. You can't fragment a stack, block allocators have predetermined fragmentation behavior, heap is "who knows" It is possible to malloc() and free() for a very small net-total, and yet be no longer able to allocate a contiguous region that is a significant fraction of the heap.
With a modern VM system, it's not quite as big a deal since your heap is effectively infinite for many applications. It is still an issue on embedded systems, and was a problem back in the day too.
Question from a newbie C developer: How can you avoid using malloc? Are you finding some clever way to do everything on the stack? Or are you perhaps allocating a large block of contiguous memory and slicing it up on your own?
I've heard of both of those approaches and they sound pretty hard, so I'd be interested to hear your thoughts/be pointed to good references on the topic. Thanks in advance.
A lot of the time, the nature of the data and its lifetime makes specialized allocators easy to use. Not infrequently they can actually be more convenient than malloc/free when you have a bunch of allocations (think nodes in a parse tree) with the same lifetime, so their storage can be released as a single operation. For that example, you can get the same usability with a more traditional malloc/free interface using something like hmalloc, but if the parse tree nodes all occupy the same contiguous block, you get it automatically. And of course it's a lot faster to release a single block (if you release the storage back to the OS, the page manager will still have some per-page work for a virtually contiguous block of memory).
Basically, once you have a nailed down system design, it's usually not any significant extra work to use custom allocators. Where it can suck away your productivity is during iterative design and development where you're still figuring out the different kinds of data, what subsystems exist and who owns what when. But in that scenario, garbage collection is even easier than malloc/free, so it's not a mortal sin to use Bochs or just leak memory (heresy!) if you can get away with it--only temporarily, of course, while you figure out the design.
There's a large block of memory that's easy to slice up on your own. It's called the BSS section, which is where global and static variables without an initial value are stored. BSS gets zeroed before main() is called.
This isn't possible in all cases, but for embedded software especially it's often possible to create all data structures as global or static variables. The compiler takes care of alignment concerns for you, and you're guaranteed not to have heap issues because you never use the heap. Of course, you can run out of the objects you pre-allocated in BSS, but that's an easier problem to diagnose and fix.
1. Most of the compilers restrict the size of Stack to be much less than the size of heap.
2. If you use the space of this stack for dynamic memory allocation as well, you will be limiting your capacity to write recursive functions.
3. it will depend on the kind of system you are developing. If you are developing some tool to analyze millions of tweets, you have to use "heap" there is no alternate. If you are developing an embedded application " say loading your list of conatcts for sending the message yes there you can get away with allocating the memory on stack itself. But then there most of the phones do not allow you to make a list of more than 25-30 people.
So it depends on the application one is willing to develop and K&R well recognized it in early 70s itself that is why they introduced alloca in addition to malloc , calloc
I never said you should put everything on the C stack. I also never said you couldn't use dynamic memory. You can have a custom stack or block allocator with memory coming from sbrk() mmap() or preallocated in the bss.
Well, if the money supply kept up perfectly with economic growth then the value of money would stay the same. Inflation is extra money supply expansion.
I don't see any reason to reinterpret this as an anti-government pamphlet. It's just pointing out that economic conditions and mentality are changing around the world, but that this is often overlooked in the news cycle because politicians don't report on it when it is not their personal achievement.
I agree entirely with the sentiments about politicians - but this article confuses "government" with "politics" and assumes the market solved problems without any influence from prior sources.
There is zero analysis or even allusion to what factors might have influenced the demand that ultimately caused the market to react. Just a blanket statement about how the governments of the world aren't doing anything useful.
Come on you incorrigible pessimists, lighten up. There is obviously some tongue-in-cheek and inaccuracies in the article, but also some profound truth. This is the greatest time in history to be alive as a human and we might as well recognize that.
Thanks as well digeridoo! There is a Western pessimism in our economic slump, but come on (!) we live in this crazy world of internet in your pocket in the West while most of the world is getting better. Yes, there are a ton of problems, but it's at least recognize that we've got it better than ever - and it's okay to want to improve it - that's how we got here!
BTW - if you're pessimistic/angry, but you're still working on a social-mobile-gamified-deals-app - please become part of the solution [1] if you really think things are going down.
[1] Not saying you're part of the problem, just neutral.
Thank you. Please never forget about the problems going on in the world, but take the time to appreciate what you got, and what we indeed have accomplished, during the last couple of years. We're doing good, but we can do even better. I don't see any harm in celebrating that.
Well, that's only true when the world is progressing towards a better tomorrow. There are plenty of times when it hasn't been true -- say, during the Late Bronze Age Collapse.
Something that seems counter-intuitive given the usual headlines is that, since the end of the Great African War, we now live in the most peaceful time in all of human history. There are no major wars in the entire world. That is pretty remarkable.
In old school or new school C, there's every reason to minimize the use of malloc and it's easy to avoid.