125
As shown in the preceding example, it is very important to realize that storing
volatile memory pointers in persistent memory is almost always a design error.
However, using the pmem::obj::persistent_ptr<> class template is safe. It provides
the only way to safely access specific memory after an application crash. However,
the pmem::obj::persistent_ptr<> type does not satisfy TriviallyCopyable
requirements because of explicitly defined constructors. As a result, an object with a
pmem::obj::persistent_ptr<> member will not pass the std::is_trivially_copyable
verification check. Every persistent memory developer should always check whether
pmem::obj::persistent_ptr<> could be copied in that specific case and that it will
not cause errors and persistent memory leaks. Developers should realize that std::is_
trivially_copyable is a syntax check only and it does not test the semantics. Using
pmem::obj::persistent_ptr<> in this context leads to undefined behavior. There is no
single solution to the problem. At the time of writing this book, the C++ standard does
not yet fully support persistent memory programming, so developers must ensure that
copying pmem::obj::persistent_ptr<> is safe to use in each case.
Limitations Summary
C++11 provides several very useful type traits for persistent memory programming.
These are
• template
struct std::is_pod;
• template
struct std::is_trivial;
• template
struct std::is_trivially_copyable;
• template
struct std::is_standard_layout;
They are correlated with each other. The most general and restrictive is the definition
of a POD type shown in Figure 8-1.
Chapter 8 libpmemobj-Cpp: the adaptable language - C++ and persistent memory
Précédent

- 151/457

Suivant