The formal parameter of the stuff_with_a function declares at stack level a huge matrix, while the correct way of doing this is using pointers.
Just try to compare assembly code obtained by the following versions of the same function:
void foo(char **x, size_t n, size_t m) {
uint32_t i,j;
for (i=0; i<n; i++)
for (j=0; j<m; j++)
x[i][j] = 0;
}
void foo(char x[1000][10]) {
uint32_t i,j;
for (i=0; i<1000; i++)
for (j=0; j<10; j++)
x[i][j] = 0;
}
You will notice that the first version is much more good!
Name:
Anonymous2008-11-15 11:10
char* a = (char*) calloc(20000000*20, sizeof(char)); 1. Just use memset
way to entirely miss the point, faggots. the idea is to use malloc and then use the a[i][j] syntax to access the array, without wasting 20000000 pointers worth of memory.
>>3 The formal parameter of the stuff_with_a function declares at stack level a huge matrix, while the correct way of doing this is using pointers.
I was under the impression that arrays were passed by-reference: if you declared the array in the body of the function, it would be stack-allocated. In this case, however, I think the compiler would implicitly convert the pointer to an array and not push it onto the stack.
Name:
Anonymous2008-11-15 16:05
>> 13
Here 3 speaking.
If you don't believe me, just try to produce the relative code with gcc -S, and than you'll shit bricks!
>>14
Given the input file, test.c: void func( int a[9001] ) {
a[0] = 1;
}
gcc -S produces the following -- .file "test.c"
.text
.p2align 4,,15
.globl func
.type func, @function
func:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %eax
movl $1, (%eax)
popl %ebp
ret
.size func, .-func
.ident "GCC: (GNU) 4.2.1 20070719 [FreeBSD]"
tl;dr it's passing by-reference, as I thought it did. No bricks have been shat.
Name:
Anonymous2008-11-16 3:01
>>18
Now with two-dimensional arrays please, smartass
Name:
Anonymous2008-11-16 3:09
>>18
You're right, putting an array size in the formal parameter does nothing--it's just to make the programmer feel warm and fuzzy. The compiler just ignores that size and treats it like a pointer, so there's no harm.
>>32
No, but you are the only one that parenthesises the return value.
Name:
Anonymous2008-11-17 16:50
>>33
Ugh, I hate that, too. return is a statement, not a function! I also hate it when programmers put extraneous parenthesis, especially around Boolean logic. "foo > bar && bar != baz" is much easier to read than "(foo > bar) && (bar != baz)".
Name:
Anonymous2008-11-17 17:07
>>33 >>34
Superfluous parentheses are pig disgusting. However, I have the habit to always parenthesize my use of sizeof even though it's not necessary. I like to think of it as a function returning a size_t. Don't think I've ever seen anyone else do that. An expression like sizeof(x)*4 instead of sizeof x * 4 lets me sleep at night.
Name:
Anonymous2008-11-17 17:35
>>35
Huh, I was under the impression that sizeofrequired parenthesis.
#include <stddef.h>
int main()
{
size_t a = sizeof int;
return 0;
}
test.c: In function ‘main’:
test.c:5: error: expected expression before ‘int’