Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A venerable and completely reasonable approach for resource-constrained environments and/or programs with very small memory requirements (kilobytes).


What are your issues with the memory requirements being small? One of the programs was a MUD that consumed a couple hundred megabytes, and I never had issues with it.

I mentioned gigabytes because of how mine specifically worked. It allocated chunks in powers of 2, so there was some % of memory that wasn't being used. For instance, If you only need 20 bytes for a string, you got back a pointer for a chunk of 32 bytes. Being just a game, and side project, I never gave it much thought, so I'm curious to hear your input.


What makes you think that this approach is only useful for resource-constrained circumstances?


Yeah it's reasonable. Unfortunately if you do it, and you run tools like Coverity, it'll produces reams of complaints about how you're leaking memory :-( There was one project which was genuinely a short-lived program that never needed to free memory, but in the end I gave in and added free() statements everywhere. Otherwise we could never have got it into RHEL.


Why not just put all the free()s at the end of main() behind an #ifdef DEBUG or something?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: