CODEWITHSUNDEEP
c++c++11language-lawyerreallocobject-lifetime
BeeOnRope
BeeOnRope

Reputation: 64987

Can the storage of trivially copyable objects be safely reallocated with realloc?

I know that trivially copyable objects can safely be copied my malloc into an appropriate storage location1 and that the destination object will have the same value as the source.

Is this also possible with realloc? That is, if realloc some storage containing some objects of type T, and realloc decides to move and copy the block, will the objects in the newly allocated storage be intact and have started their lifetime, and will the lifetime of the objects in the old storage be safely ended?

1 While asking this question, I had assumed that an "appropriate storage location" included uninitialized storage of suitable alignment and size, but as M.M's answer below argues this isn't actually well supported by the standard. That would make realloc questionable since it is always copying into uninitialized storage.

Upvotes: 8

Views: 428

Answers (2)

curiousguy
curiousguy

Reputation: 8288

3.8 Object lifetime is clear:

The lifetime of an object of type T begins when:

1.1 storage with the proper alignment and size for type T is obtained, and

1.2 if the object has non-vacuous initialization, its initialization is complete.

And same of end of lifetime. You can ignore the garbage in the other parts of the std, like [intro]!

Upvotes: -3

M.M
M.M

Reputation: 141628

No, realloc cannot be used to safely move objects, even of trivially copyable types, because realloc cannot create new objects in uninitialized storage.

In particular, according to C++14 [basic.life]/1:

The lifetime of an object of type T ends when:

  • if T is a class type with a non-trivial destructor (12.4), the destructor call starts, or

  • the storage which the object occupies is reused or released.

Calling realloc releases or reuses the storage (even if a reallocation doesn't occur, I'd argue, although that is moot for your question). So the lifetime of the objects ends.

The cases when an object is created is covered by [intro.objects]/1:

An object is created by a definition (3.1), by a new-expression (5.3.4) or by the implementation (12.2) when needed.

This does not include realloc; so the realloc call ends the lifetime of the old objects and does not create new objects.

Not only does this imply that realloc isn't suitable to copy trivially copyable objects, it also implies that using malloc or operator new(size_t) to obtain uninitialized storage, followed by a memcpy from an existing object into that storage does not create a usable copy of the object as the destination object has also not been created in that case.

See also: reinterpret_cast creating a trivially-default-constructible object, or constructing a trivially copyable object with memcpy for further discussion of the fact that copying bytes to a new location does not create an object in that location.

Upvotes: 9

Related Questions