`std::realloc` for non-POD types [duplicate]

Answer 1

No, not safe.

For the simpler things that you are imagining you can get away with it.

But imagine a structure that uses a class variable to track the location of each of its objects. Now you copy that with realloc instead of constructors and assignment operators and the structure is all wrong because the code broke the rules.

Answer 2

When realloc is asked to extend an allocated area it can succeed in two different ways:

• realloc can somehow extend the area, so it keeps its address but gets larger. This is unproblematic as long as the new part is treated as uninitialized storage.

• realloc can allocate a suitable new area, copy the data over, and deallocate the original area. Problem 1: the copying is not always appropriate for a type that takes charge of copying or moving. Problem 2: Pointers and references to objects in the original area, are now invalid.

It's easy to think of cases where it will work for a non-POD items, and it's also easy to think of cases where it will not work. Perhaps easiest for not-work, a Node type for a linked structure, where the nodes have pointers to each other.

The upshot is that one can get a real speed improvement (e.g. CPython uses realloc for its string handling), but std::vector is too general a beast to make use of this. One needs some more dedicated custom container. AFAIK there's no such in Boost, but there might just be even if I haven't heard of it.