Jump to content
  • Advertisement
Sign in to follow this  
3dmodelerguy

change size of char array

This topic is 3703 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
Assuming C or C++ ...

A statically allocated array cannot be resized.

Either allocate an array on the heap, or use something like std::vector<>

Share this post


Link to post
Share on other sites
Assuming C++, this is exactly what std::string is for. If not, you'd have to use malloc(), or something like alloca() to allocate stack space.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
... or something like alloca() to allocate stack space.


I learned something new. Where would one use a function like alloca()?

Share this post


Link to post
Share on other sites
Quote:
Original post by fpsgamer
Quote:
Original post by Evil Steve
... or something like alloca() to allocate stack space.


I learned something new. Where would one use a function like alloca()?
alloca(). It works exactly the same way as malloc(), except you're limited by stack space rather than heap space, and you don't need to free() it - the memory gets freed when the function returns (Which also means you can't use it to allocate memory that you return from a function).

One use would be for reading data from a file or something that you don't know the size of, then you could malloc() the correct size, memcpy() into it and return the malloc()'d pointer.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
Quote:
Original post by fpsgamer
Quote:
Original post by Evil Steve
... or something like alloca() to allocate stack space.


I learned something new. Where would one use a function like alloca()?
alloca(). It works exactly the same way as malloc(), except you're limited by stack space rather than heap space, and you don't need to free() it - the memory gets freed when the function returns (Which also means you can't use it to allocate memory that you return from a function).

One use would be for reading data from a file or something that you don't know the size of, then you could malloc() the correct size, memcpy() into it and return the malloc()'d pointer.


So where does it allocate the memory? Does it allocate it immediately after the current stack frame (no gaps?), or could it possibly allocate it anywhere within the available empty stack memory? If its the second one, wouldn't that eventually interfere when more stack frames are pushed onto the stack?

Secondly, in the analogy you provided, why would we use a alloca() + malloc()? Don't we risk easily overflowing the stack? Is the benefit a speed increase? Searching for a free block of memory on the stack should be a constant time operation -- right?

Share this post


Link to post
Share on other sites
Your typical alloca() implementation just increments the stack pointer by the size of the requested memory block (rounded up for alignment), effectively increasing the size of the current stack frame by the requested size. (Replace stack pointer by frame pointer or whatever mechanism is used to determine the end of the current stack frame on the given platform is.) It generally exploits the same mechanisms used to denote stack frames for variadic functions, which means that alloca() may not be usable on some platforms in functions that don't use the standard C calling convention.

Share this post


Link to post
Share on other sites
Quote:
Original post by fpsgamer
So where does it allocate the memory? Does it allocate it immediately after the current stack frame (no gaps?), or could it possibly allocate it anywhere within the available empty stack memory? If its the second one, wouldn't that eventually interfere when more stack frames are pushed onto the stack?
What SiCrane said. It just adds to the current stack frame.

Quote:
Original post by fpsgamer
Secondly, in the analogy you provided, why would we use a alloca() + malloc()? Don't we risk easily overflowing the stack? Is the benefit a speed increase? Searching for a free block of memory on the stack should be a constant time operation -- right?
alloca() to perform very fast allocations, and then malloc() to allocate the final buffer. Memory allocated with alloca() has the same properties as a local variable; it's cleaned up when the function exits, so you couldn't return the pointer allocated with alloca() to the calling function, because it's been freed by that point. Passing it along to functions still to be called from the function that allocated the memory is ok though.
And yes, it can quite easily overflow the stack if you're not careful - particularly since you can't free the memory without exiting the current function.

In fact, the more I think about it, the more I realise it's a bad idea - you might just as well allocate a static buffer that's the largest size you think you'll need. If you need larger than that, you could return an error, or use malloc() to allocate another large chunk.

Share this post


Link to post
Share on other sites
It depends on the purpose of the buffer. If the idea is to return it, then you might as well malloc() it in the first place and realloc() it if it needs to be resized (in C anyways).

Share this post


Link to post
Share on other sites
Using vectors is the best solution. But if you don't know anthing about vectors (like me), you can use this trick :

/* We define an array */
int old_size = 20;
char data[old_size];

/* Later, we regret it and decide to change its size */
int new_size = 30;
char temp[old_size];
for (int i=0; i<old_size; i++) temp = data;
delete data;
char data[new_size];
for (int i=0; i<old_size; i++) data = temp;
delete temp;

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!