To the best of my understanding, it is largely equivalent to say:<p>int * i;<p>i = (int * ) malloc(10 * sizeof(int));<p>as it is to say:<p>int * i;<p>i = (int*) calloc(10,sizeof(int));<p>The one allocates a memory block of size 10 times sizeof(int), the other allocates ten memory blocks each of size sizeof(int) and has them all initialized to 0. So effectively the only difference in this case is calloc initializes the blocks to 0 whereas malloc does not. And calloc is more computationally expensive. But in the end a similar result obtains.<p>Normally I use malloc, but out of curiousity I read up about calloc and this seems to be the answer, that they are basically the same except calloc initializes n number of blocks to size size_t instead of 1 block of some given size size_t, calloc initializes the values to 0 where malloc does not, and calloc takes more time for the cpu to do than malloc does. So with some minor differences the above two statements should do the same thing - i.e. I can use the int arrays allocated thusly the same. I think. :-)<p>Anybody have any thoughts? Which is better to use normally?<p>(by the way http://www.cs.cf.ac.uk/Dave/C/node11.html is where I was reading up on these functions)
Calloc clears the memory to all bits zero. All bits zero doesn't necessarily mean zero values. Not many people will make this distinction and happily write broken code thinking that calloc always clears the values to zero accordingly.<p>calloc's zero fill is all-bits-zero, and is therefore guaranteed to yield the value 0 for all integral types, and '\0' for character types -- but does not guarantee useful null pointer values or floating-point zero values.<p>Some C implementations represent null pointers by special, nonzero bit patterns when it can be arranged so that inadvertently using those values triggers automatic hardware traps.
First: Lose the cast. It's not needed in C, clutters the code, and can hide real problems (like implicit declarations of the functions -- this can cause crashes on 64-bit architectures). A void* exists solely so it can be assigned to any type* without casts. It's useless for any other purpose.<p>Yes, they are effectively the same. I'd suspect that on most systems (glibc, certainly) calloc more or less does:<p><pre><code> mem = malloc(nelem * size);
memset(mem, 0, nelem * size);
return mem;</code></pre>
From the openbsd man page malloc(3):<p>When using malloc() be careful to avoid the following idiom:<p><pre><code> if ((p = malloc(num * size)) == NULL)
err(1, "malloc");
The multiplication may lead to an integer overflow. To avoid this, calloc() is recommended.</code></pre>
I always use calloc when allocating many blocks at once, as you said. Yes, you get a free bzero() with it, but that's not why I use it.<p>When I'm trying to allocate memory for many blocks of something, I'd use calloc just because it makes my intentions clearer in the code when someone else is reading it. If I'm allocating memory just for one area or block, I'd use malloc+bzero or possibly calloc with a clear block count of one. The efficiency in the end is pretty equivalent but it makes your code easier to digest to other people.
calloc by default, then <i>profile your code</i>, and if memset or calloc hits the top of the profile, start pruning them out.<p>You get a much bigger performance win out of swapping in a pool allocator, or, even better, arenas.
If you want the benefit of the clearness of calloc without the time wasted on memset--just write a wrapper for malloc. Its not much effort, and it gets you the best of both worlds.
i only use calloc when i have any chance of addressing an area that could ever potentially be empty. i more typically malloc if i'm making space and immediately fill it up completely with whatever goes in it so that any of the previous garbage is gone