120
This problem is well known and is being addressed by the WG21 C++ Standards
Committee Working Group (https://isocpp.org/std/the-committee and http://
www.open-std.org/jtc1/sc22/wg21/).
Currently, there is no possible way to overcome the object-lifetime obstacle and
stop relying on undefined behavior from C++ standard’s point of view. libpmemobj-cpp
is tested and validated with various C++11 compliant compilers and use case scenarios.
The only recommendation for libpmemobj-cpp users is that they must keep this
limitation in mind when developing persistent memory applications.
Trivial Types
Transactions are the heart of libpmemobj. That is why libpmemobj-cpp was implemented
with utmost care while designing the C++ versions so they are as easy to use as possible.
Developers do not have to know the implementation details and do not have to worry about
snapshotting modified data to make undo log–based transaction works. A special semitransparent template property class has been implemented to automatically add variable
modifications to the transaction undo log, which is described in the “Snapshotting” section.
But what does snapshotting data mean? The answer is very simple, but the
consequences for C++ are not. libpmemobj implements snapshotting by copying data of
given length from a specified address to another address using memcpy(). If a transaction
aborts or a system power loss occurs, the data will be written from the undo log when the
memory pool is reopened. Consider a definition of the following C++ object, presented
in Listing 8-4, and think about the consequences that a memcpy() has on it.
Listing 8-4. An example showing an unsafe memcpy() on an object
35
class nonTriviallyCopyable {
36
private:
37
int* i;
38
public:
39
nonTriviallyCopyable (const nonTriviallyCopyable & from)
40
{
41
/* perform non-trivial copying routine */
42
i = new int(*from.i);
43
}
44
};
Chapter 8 libpmemobj-Cpp: the adaptable language - C++ and persistent memory
This problem is well known and is being addressed by the WG21 C++ Standards
Committee Working Group (https://isocpp.org/std/the-committee and http://
www.open-std.org/jtc1/sc22/wg21/).
Currently, there is no possible way to overcome the object-lifetime obstacle and
stop relying on undefined behavior from C++ standard’s point of view. libpmemobj-cpp
is tested and validated with various C++11 compliant compilers and use case scenarios.
The only recommendation for libpmemobj-cpp users is that they must keep this
limitation in mind when developing persistent memory applications.
Trivial Types
Transactions are the heart of libpmemobj. That is why libpmemobj-cpp was implemented
with utmost care while designing the C++ versions so they are as easy to use as possible.
Developers do not have to know the implementation details and do not have to worry about
snapshotting modified data to make undo log–based transaction works. A special semitransparent template property class has been implemented to automatically add variable
modifications to the transaction undo log, which is described in the “Snapshotting” section.
But what does snapshotting data mean? The answer is very simple, but the
consequences for C++ are not. libpmemobj implements snapshotting by copying data of
given length from a specified address to another address using memcpy(). If a transaction
aborts or a system power loss occurs, the data will be written from the undo log when the
memory pool is reopened. Consider a definition of the following C++ object, presented
in Listing 8-4, and think about the consequences that a memcpy() has on it.
Listing 8-4. An example showing an unsafe memcpy() on an object
35
class nonTriviallyCopyable {
36
private:
37
int* i;
38
public:
39
nonTriviallyCopyable (const nonTriviallyCopyable & from)
40
{
41
/* perform non-trivial copying routine */
42
i = new int(*from.i);
43
}
44
};
Chapter 8 libpmemobj-Cpp: the adaptable language - C++ and persistent memory