119
What does the preceding mean from a C++ and libpmemobj’s perspective? There are
four major problems:
1. Object lifetime
2. Snapshotting objects in transactions
3. Fixed on-media layout of stored objects
4. Pointers as object members
These four problems will be described in next four sections.
An Object’s Lifetime
The lifetime of an object is described in the [basic.life] section of the C++ standard
(https://isocpp.org/std/the-standard):
The lifetime of an object or reference is a runtime property of the object or
reference. A variable is said to have vacuous initialization if it is defaultinitialized and, if it is of class type or a (possibly multi-dimensional) array
thereof, that class type has a trivial default constructor. 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) its initialization (if any) is complete (including vacuous initialization) ([dcl.init]), except that if the object is a union member or subobject
thereof, its lifetime only begins if that union member is the initialized member in the union ([dcl.init.aggr], [class.base.init]), or as described in [class.
union]. The lifetime of an object of type T ends when:
(1.3) if T is a non-class type, the object is destroyed, or
(1.4) if T is a class type, the destructor call starts, or
(1.5) the storage which the object occupies is released, or is reused by an
object that is not nested within o ([intro.object]).
The standard states that properties ascribed to objects apply for a given object only
during its lifetime. In this context, the persistent memory programming problem is
similar to transmitting data over a network, where the C++ application is given an array
of bytes but might be able to recognize the type of object sent. However, the object was
not constructed in this application, so using it would result in undefined behavior.
Chapter 8 libpmemobj-Cpp: the adaptable language - C++ and persistent memory
What does the preceding mean from a C++ and libpmemobj’s perspective? There are
four major problems:
1. Object lifetime
2. Snapshotting objects in transactions
3. Fixed on-media layout of stored objects
4. Pointers as object members
These four problems will be described in next four sections.
An Object’s Lifetime
The lifetime of an object is described in the [basic.life] section of the C++ standard
(https://isocpp.org/std/the-standard):
The lifetime of an object or reference is a runtime property of the object or
reference. A variable is said to have vacuous initialization if it is defaultinitialized and, if it is of class type or a (possibly multi-dimensional) array
thereof, that class type has a trivial default constructor. 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) its initialization (if any) is complete (including vacuous initialization) ([dcl.init]), except that if the object is a union member or subobject
thereof, its lifetime only begins if that union member is the initialized member in the union ([dcl.init.aggr], [class.base.init]), or as described in [class.
union]. The lifetime of an object of type T ends when:
(1.3) if T is a non-class type, the object is destroyed, or
(1.4) if T is a class type, the destructor call starts, or
(1.5) the storage which the object occupies is released, or is reused by an
object that is not nested within o ([intro.object]).
The standard states that properties ascribed to objects apply for a given object only
during its lifetime. In this context, the persistent memory programming problem is
similar to transmitting data over a network, where the C++ application is given an array
of bytes but might be able to recognize the type of object sent. However, the object was
not constructed in this application, so using it would result in undefined behavior.
Chapter 8 libpmemobj-Cpp: the adaptable language - C++ and persistent memory