Best practice for allocating memory per input

[Somersett]

My program uses a buffer to store data as entered by the user, so that the size of the buffer depends on them. The first thing that came to mind is that I would reallocate memory each time more storage is needed, but that doesn't seem reasonable as the data is small and the program would constantly be reallocating. How does one generally deal with a constantly expanding buffer?

[ahamed101]

One thing is you need to reallocate memory dynamically... As you say calling realloc always for small data size ain't a good idea... In such a case you can allocate chunks of memory at time... like 32 bytes, 64 bytes, 128 bytes and so on... whenever your data exceeds the allocated memory, reallocate in these chunks... so that the call to realloc reduces and the memory allocation can be handled efficiently...

[Salem]

What are you planning to do with the input, when you've finished reading it?

[Somersett]

One thing is you need to reallocate memory dynamically... As you say calling realloc always for small data size ain't a good idea... In such a case you can allocate chunks of memory at time... like 32 bytes, 64 bytes, 128 bytes and so on... whenever your data exceeds the allocated memory, reallocate in these chunks... so that the call to realloc reduces and the memory allocation can be handled efficiently...

It occurred to me that I might just increase the size of the chunk being reallocated, but burning questions arose: How do I determine what's a large enough size? I have trouble choosing things arbitrarily like this, and I begin to wonder whether reallocating single integers wouldn't affect my program at all? Why is this bad? What will happen?

What are you planning to do with the input, when you've finished reading it?

Three buffers contain the attributes of events which are shown graphically, and can be added to and selected & edited by the user. Eventually the data in these three buffers will be combined to generate one buffer of data for output.

[ahamed101]

It occurred to me that I might just increase the size of the chunk being reallocated, but burning questions arose: How do I determine what's a large enough size? I have trouble choosing things arbitrarily like this, and I begin to wonder whether reallocating single integers wouldn't affect my program at all? Why is this bad? What will happen?.

As you are the programmer, you should be knowing the initial size of the data that will be coming... Moreover, does the increase in data size constant?... or is it varying?... If its constant, then the job is easier... if its varying you might want to find the maximum possible size and allocate accordingly...
Anyways, whats the application all about?...

[Somersett]

As you are the programmer, you should be knowing the initial size of the data that will be coming... Moreover, does the increase in data size constant?... or is it varying?... If its constant, then the job is easier... if its varying you might want to find the maximum possible size and allocate accordingly...
Anyways, whats the application all about?...

Yes, the size of the data is constant. Basically the user enters two integers and these are added to their respective buffers. These describe the attributes of audio events. The user should be able to make this audio channel as long as he would like, obviously this would be restricted to the total memory available. It's unlikely the user would take up all available memory, at the same time just arbitratily assigning a large array irks me. It seems like the concept of an expanding buffer would be a common occurrence in programming. I've been told about some implementation of this in C++ using the STL, but I want to use C.

[Sci@phy]

Well, if you're not going to acces members randomly but from begining to the end, maybe list would be perfect?

On the other hand, you could use realloc for every n members (you choose n, but I wouldn't go over 100 if user input is small)

[Somersett]

Well, if you're not going to acces members randomly but from begining to the end, maybe list would be perfect?

The user has the option to (and most likely will) edit the values in the channel.

On the other hand, you could use realloc for every n members (you choose n, but I wouldn't go over 100 if user input is small)

As I posted above, I realize that I can increase the reallocation size to an arbitrary value. But I don't know what is considered efficient or inefficient. I don't even know that reallocating for every integer is inefficient. Where does 100 come from?

[Sci@phy]

From my head :P

Seriously, reallocating for every integer may not be SO time consuming because on most of the time, realloc could just append to existing memory space. But it still IS time consumin considering the time that takes for that function to do it's stuff :)
So, define some number at begining of your code (I said 100 because I wouldn't go below 50, it's not a big size for 1GB RAM, and wouldn't go above 1000, it seems to me a pretty large number, although 1GB is 1GB :) ) and see is your program running smoothly... Then maybe try increasing/decreasing...

Basically, you need std::vector from C++.
Try to find something about it on net, and then try to make something like that in your C code. Here's one link:
http://www.cplusplus.com/reference/stl/vector/

And this is how std::vector reallocates:
whenever it runs out of space, it doubles the size of itself. Maybe you could try something like that?

[Somersett]

And this is how std::vector reallocates:
whenever it runs out of space, it doubles the size of itself. Maybe you could try something like that?

Cool. Since I'm new to C and memory allocation isn't discussed much in the books, I guess I just wanted to know whether it boiled down to tweaking values relative to the program or whether there was already some standard (or most efficient) way of doing certain things in C that only others programmers could show me.

The idea of doubling wasn't something I had thought of, and is a bit less irksome to me than plucking numbers out of the air. Thank you. I'd still like to see how others approach this concept, if there isn't a clearly traditional way.