18

For the Standard allocator interface for use in, say, std::vector, is re-allocation supported? I have a rather specific use-case in which being able to realloc directly would be much more efficient than allocating, moving, and freeing.

Edit: Sorry- I have absolutely no intention of calling the actual realloc, I meant a function with those semantics. Effectively, I'm allocating off a stack in the background, and if I allocate more off the stack, then I can't free the memory underneath it, which is a total waste because there's no need to allocate again anyway as there's plenty of contiguous free space available. Thus, if I could be asked to reallocate in a single step, then I could avoid having to firstly, allocate some stuff and waste some memory, and secondly, move all the contents of the vector.

ildjarn
  • 62,044
  • 9
  • 127
  • 211
Puppy
  • 144,682
  • 38
  • 256
  • 465

3 Answers3

22

We tried but failed:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1953.html

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html

Edit: I know what you meant. ;-)

Howard Hinnant
  • 206,506
  • 52
  • 449
  • 577
  • 2
    What does the word "failed" mean here? Failed to convince the committee? – Patrick Fromberg Sep 05 '19 at 11:30
  • 2
    Yes. The proposals linked in the answer were submitted and rejected. – Howard Hinnant Sep 05 '19 at 13:37
  • 1
    There was a more recent proposal - https://github.com/cplusplus/papers/issues/123 also rejected. I personally think it is inferior to the ones from 2006. – Bruce Adams May 10 '22 at 09:52
  • 3
    We have some progress with sized feedback from allocators being accepted into C++23 - see https://github.com/cplusplus/papers/issues/18 & https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0901r5.html – Bruce Adams May 10 '22 at 10:40
2

I believe that realloc() is not part of the STL allocator interface. But realloc() is always a crap-shoot anyway, since you don't really know whether your OS will expand your allocation or move you to a new one. Actual performance is very OS-dependent. If you know you want to reallocate, you might as well just alloc a bigger chunk of memory in advance, which luckily the STL makes easy.

Do you have a use case where this would be undesirable?

Jacob B
  • 2,005
  • 13
  • 12
  • It would be desirable in custom allocators, for example a simple area allocator. Currently, you need to waste at least a half of the pre-allocated memory if you are backing a container like std::vector. – ciechowoj Oct 28 '16 at 18:24
  • I agree but want to add something here. If you reserve more memory than you need for a big vector, then you do not waist memory at all. You only waist virtual memory which is ok if you do not overdo it. This does not work for small vectors as virtual memory is managed in chunks of 4k byte pages. – Patrick Fromberg Sep 05 '19 at 11:41
0

You can put a bool flag in the structure you are saving in the std::vector to indicate it its logically deleted or not. To delete an element set this flag to true but don't physically delete it. To reallocate an element, look for an flag that's true, set it to false to show its not deleted and that use it.

mike jones
  • 649
  • 4
  • 15