Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Ken Brody <kenbrody@spamcop.net> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: trouble of static working-data-buffers size assumption |
| Date | 2015-08-11 11:25 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <mqd437$m80$1@dont-email.me> (permalink) |
| References | <7654f359-9404-4818-a877-b3a0d5c32d05@googlegroups.com> <b292d473-024c-465c-917e-54bc594ec37b@googlegroups.com> <mqalim$298$1@dont-email.me> <e9706a97-08e4-439c-a228-22645d87f6f0@googlegroups.com> |
On 8/10/2015 2:25 PM, fir wrote: > W dniu poniedziałek, 10 sierpnia 2015 19:06:10 UTC+2 użytkownik Ken Brody > napisał: [...] >> I usually just use malloc/realloc, and keep track of my current >> allocation size. I then have a quick to see if the current buffer is >> big enough, and realloc if not, storing the new size. (Sometimes, I'll >> realloc to X bytes larger than the currently-required amount, to reduce >> realloc calls and possible memory fragmentation.) >> > > what memopry fragmentation? realloc will give you solid ram chunk, afaik > no trouble with it.. What happens when you try to realloc the buffer larger, but malloc has already allocated the memory immediately following the current buffer? It must get you a new buffer. Then, when you realloc again for a larger buffer, it's possible that the memory immediately following the new buffer is also already allocated, so another buffer needs to be returned. (This is probably more noticeable when starting with small buffers, with small increments in size.) You now have chunks of allocated memory with small chunks of now-free memory, which may or may not ever get allocated, scattered amongst them. I didn't mean that realloc() would return a "fragmented" buffer (such as disk storage), but rather that the malloc "heap" would become fragmented. >> No matter how big you make the static buffer, there will be some >> scenario where it's not large enough. What do you do then? >> > well this leeds me to reallocs.. but in reallity it is some trade-off > assumptions for reallocs, not 100% clear choice.. though im like to seem > change to reallocs (last few years i prefered statics and assumptions now > wonder if to change side) Well, you still have to handle the case of "I need more memory than the static buffer I reserved". -- Kenneth Brody
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
trouble of static working-data-buffers size assumption fir <profesor.fir@gmail.com> - 2015-08-10 07:42 -0700
Re: trouble of static working-data-buffers size assumption fir <profesor.fir@gmail.com> - 2015-08-10 07:48 -0700
Re: trouble of static working-data-buffers size assumption Ken Brody <kenbrody@spamcop.net> - 2015-08-10 13:05 -0400
Re: trouble of static working-data-buffers size assumption fir <profesor.fir@gmail.com> - 2015-08-10 10:21 -0700
Re: trouble of static working-data-buffers size assumption fir <profesor.fir@gmail.com> - 2015-08-10 10:52 -0700
Re: trouble of static working-data-buffers size assumption fir <profesor.fir@gmail.com> - 2015-08-10 11:25 -0700
Re: trouble of static working-data-buffers size assumption Ken Brody <kenbrody@spamcop.net> - 2015-08-11 11:25 -0400
Re: trouble of static working-data-buffers size assumption Richard Damon <Richard@Damon-Family.org> - 2015-08-10 22:36 -0400
Re: trouble of static working-data-buffers size assumption Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 22:54 -0700
Re: trouble of static working-data-buffers size assumption Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-11 13:41 +0100
Re: trouble of static working-data-buffers size assumption Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-11 08:27 -0700
Re: trouble of static working-data-buffers size assumption David Brown <david.brown@hesbynett.no> - 2015-08-10 18:22 +0200
csiph-web