realloc variants

Question

Just to situate the context: it's about a string pool, meaning a hash table with string keys (actually special strings that know their length, but I guess this detail is irrelevant here). The point is the resizing of the array of lists (used as table buckets) when the pool needs to grow. But --this is the core detail-- cells containing string actually in an array of cells, instead of being spread out in all corners of memory [1]. Thus, I don't need the lists anymore, they're just outdated stuff. So:

1. Is there a variant of realloc that "zeroes" the memory area like calloc? I need that here because the items are not only pointers, but lists heads: the issue is to ensure an empty list is/shows as NULL. Else, is the best solution just to memset(p, size, 0);

2. Is there a variant of realloc that does not copy if ever there is not enough space to grow on place, but instead just allocates like alloc? The issue here is that I don't need the data anymore, since strings need to be re-distributed in lists according to new modulo. Else, what is the best choice?

   • use realloc
   • (free &) use alloc
   • (free &) use calloc

Is this right in any case: realloc tries to alloc more space on place, else allocates elsewhere and silently copies? If yes, then maybe a problem is there are (at least) three use cases requiring different actions --in both cases where there is or there is not enough space on place-- but a single func with no option at all:

• I need more place for these data and more to come (standard).
• I need more place, but the data are garbage from now on.
• I need more space and the area to be "zeroed".

What is the best option for me? What do you think else? Where can I find more reflexions or info on the topic?

Is there a reason why alloc has a different interface from calloc and realloc? (I mean specifying total-size vs single-size & count)

[1] The point was originally to make ordered sets & maps; for a string pool it is not needed but does not bother. Instead, it makes code clearer and provides locality of reference.

Bes

Answer 1

Is there a variant of realloc that "zeroes" the memory area like calloc? I need that here because the items are not only pointers, but lists heads: the issue is to ensure an empty list is/shows as NULL. Else, is the best solution just to memset(p, size, 0);

If you're coding strictly for the standard, you're stuck with memset. At least this one is easy to work around.

If you've got some platform-specific leeway, some of them do have a recalloc function.

Is there a variant of realloc that does not copy if ever there is not enough space to grow on place, but instead just allocates like alloc? The issue here is that I don't need the data anymore, since strings need to be re-distributed in lists according to new modulo. Else, what is the best choice?

Again no, unfortunately.

There is a proposal for C1X which adds both of these features (among others), but for now you're stuck with realloc's current behavior.

Figurine

All right, thank you. When I have time, I'll try some free + new alloc just to see how often the allocator reuses just-freed memory. This would give me the best. There may be some strategy about that, since my case is fairly common (to the point they think at it for std, as you say). Not only I just free before alloc, but the compiler well knows this is with the same pointer variable... (it may let a clue for the allocator) – Bes

Answer 2

Is there a variant of realloc that "zeroes" the memory area like calloc?

No.

Is there a variant of realloc that does not copy if ever there is not enough space to grow on place, but instead just allocates like alloc?

No.

If I were you I'd probably use free and calloc. But ideally you want to design your system so that reallocations are infrequent and so the different performance characteristics of the various options are not significant. In other words, make sure that it doesn't matter which option you select.

Berman

Thank you. Things are clear, now. I'm not yet decided on the option to choose. The pool is more or less designed as you propose in that it lets you "batch store" a pack of strings all together, so that there is only one grow-up operation (if at all). What do you think? (Actually, I design all collection types with this possibility.) But, while the question is centered on this case, I'd like to know more in general. Thanks again. – Bes

I don't know. As I said, if possible, you should design the system so that allocation is not a bottleneck. The it matters not. But if you can't, then you need to time the various options. – Berman