change size of char array
Author
let say i have
char data[20];
is there any way to change data to store lets say 100 instead of 20 without the use of a pointer.
Assuming C or C++ ...
A statically allocated array cannot be resized.
Either allocate an array on the heap, or use something like std::vector<>
A statically allocated array cannot be resized.
Either allocate an array on the heap, or use something like std::vector<>
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.
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()?
Quote:Original post by fpsgameralloca(). 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).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()?
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.
Quote:Original post by Evil SteveQuote:Original post by fpsgameralloca(). 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).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()?
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?
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.
Quote:Original post by fpsgamerWhat SiCrane said. It just adds to the current stack frame.
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?
Quote:Original post by fpsgameralloca() 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.
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?
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.
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).
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;This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
