Sorry, I've been catching up and just came across the intro of _alloca. I tried searching the forum but the search functionality isn't that good or I'm doing it wrong.
I don't think I'll ever use _alloca (or _malloca) because I can't seem to figure out why it would ever be beneficial. That lends me to think that I just don't understand why it's there. What is the benefit/disadvantages of the two lines below? Don't they both allocate space on the stack of 4 bytes and get popped at the end of scope and/or function scope? They both also result in pointers.
I don't think I'll ever use _alloca (or _malloca) because I can't seem to figure out why it would ever be beneficial. That lends me to think that I just don't understand why it's there. What is the benefit/disadvantages of the two lines below? Don't they both allocate space on the stack of 4 bytes and get popped at the end of scope and/or function scope? They both also result in pointers.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | unsigned char a[4]; // no asm generated (?) // removed cast in case it generated extra asm // char* b = (char*)_alloca(4); void* b = _alloca(4); 0130142B mov eax,dword ptr [ebp-11Ch] 01301431 call __alloca_probe_16 (013011F4h) 01301436 mov dword ptr [ebp-120h],esp 0130143C lea ecx,[ebp-54h] 0130143F push ecx 01301440 mov edx,dword ptr [ebp-11Ch] 01301446 mov ecx,dword ptr [ebp-120h] 0130144C call @_RTC_AllocaHelper@12 (01301037h) 01301451 add dword ptr [ebp-120h],20h 01301458 mov edx,dword ptr [ebp-120h] 0130145E mov dword ptr [b],edx |
The benefit is that you can allocate variable amount of space from stack. You can, as I've understood, do that in "modern C" without alloca(), but that wasn't the case for a long time.
Also, allocating from stack is faster and more lightweight than allocating from heap. Personally I hit alloca() the first time when trying to port a fixed-point ogg replaying library to a platform that didn't support alloca(). =)
Also, allocating from stack is faster and more lightweight than allocating from heap. Personally I hit alloca() the first time when trying to port a fixed-point ogg replaying library to a platform that didn't support alloca(). =)
Good info, thanks.
Be careful with alloca - it frees stack only when function returns, not at end of scope. So this code will actually allocate 100KB of stack space:
1 2 3 4 5 6 7 8 | void f()
{
for (int i=0; i<1024; i++)
{
void* mem = alloca(100);
...
}
}
|
Right. We learned that lesson in the Day 12 video.
I was speaking to a colleague today and he pointed out an excellent difference. Just declaring a local variable that happens to be a pointer to stack memory is fine but the size needs to be known at compile time. Whereas with _alloca(), the size can be determined at run time. Makes a lot more sense to me know as to why it exists... I still will probably never use it. ;)
I was speaking to a colleague today and he pointed out an excellent difference. Just declaring a local variable that happens to be a pointer to stack memory is fine but the size needs to be known at compile time. Whereas with _alloca(), the size can be determined at run time. Makes a lot more sense to me know as to why it exists... I still will probably never use it. ;)
I mentioned that because you wrote in initial post, that it frees end of scope. Just so there is no confusion if somebody else reads this topic.
And yes, that is only reason why you use alloca.
But if your compiler supports C99, you can allocate variable size arrays:
And yes, that is only reason why you use alloca.
But if your compiler supports C99, you can allocate variable size arrays:
1 2 | int i = ...; char arr[i]; |
Edited by Mārtiņš Možeiko
on