.TH "cereal::memory_detail::EnableSharedStateHelper< T >" 3 "Sat Aug 29 2026 00:42:30" "cereal" \" -*- nroff -*-
.ad l
.nh
.SH NAME
cereal::memory_detail::EnableSharedStateHelper< T >
.SH SYNOPSIS
.br
.PP
.PP
\fR#include </home/build/include/cereal/types/memory\&.hpp>\fP
.SS "Public Member Functions"

.in +1c
.ti -1c
.RI "\fBEnableSharedStateHelper\fP (T *ptr)"
.br
.RI "Saves the state of some type inheriting from enable_shared_from_this\&. "
.ti -1c
.RI "void \fBrestore\fP ()"
.br
.RI "Restores the state of the held pointer (can only be done once)\&. "
.ti -1c
.RI "\fB~EnableSharedStateHelper\fP ()"
.br
.RI "Restores the state of the held pointer if not done previously\&. "
.in -1c
.SH "Detailed Description"
.PP 

.SS "template<class T>
.br
class cereal::memory_detail::EnableSharedStateHelper< T >"A helper struct for saving and restoring the state of types that derive from std::enable_shared_from_this

.PP
This special struct is necessary because when a user uses load_and_construct, the weak_ptr (or whatever implementation defined variant) that allows enable_shared_from_this to function correctly will not be initialized properly\&.

.PP
This internal weak_ptr can also be modified by the shared_ptr that is created during the serialization of a polymorphic pointer, where cereal creates a wrapper shared_ptr out of a void pointer to the real data\&.

.PP
In the case of load_and_construct, this happens because it is the allocation of shared_ptr that perform this initialization, which we let happen on a buffer of memory (aligned_storage)\&. This buffer is then used for placement new later on, effectively overwriting any initialized weak_ptr with a default initialized one, eventually leading to issues when the user calls shared_from_this\&.

.PP
To get around these issues, we will store the memory for the enable_shared_from_this portion of the class and replace it after whatever happens to modify it (e\&.g\&. the user performing construction or the wrapper shared_ptr in saving)\&.

.PP
Note that this goes into undefined behavior territory, but as of the initial writing of this, all standard library implementations of std::enable_shared_from_this are compatible with this memory manipulation\&. It is entirely possible that this may someday break or may not work with convoluted use cases\&.

.PP
Example usage:

.PP
.PP
.nf
T * myActualPointer;
{
  EnableSharedStateHelper<T> helper( myActualPointer ); // save the state
  std::shared_ptr<T> myPtr( myActualPointer ); // modifies the internal weak_ptr
  // helper restores state when it goes out of scope
}
.fi
.PP

.PP
When possible, this is designed to be used in an RAII fashion - it will save state on construction and restore it on destruction\&. The restore can be done at an earlier time (e\&.g\&. after construct() is called in load_and_construct) in which case the destructor will do nothing\&. Performing the restore immediately following construct() allows a user to call shared_from_this within their load_and_construct function\&.

.PP
\fBTemplate Parameters\fP
.RS 4
\fIT\fP Type pointed to by shared_ptr 
.RE
.PP

.SH "Constructor & Destructor Documentation"
.PP 
.SS "template<class T> \fBcereal::memory_detail::EnableSharedStateHelper\fP< T >::EnableSharedStateHelper (T * ptr)\fR [inline]\fP"

.PP
Saves the state of some type inheriting from enable_shared_from_this\&. 
.PP
\fBParameters\fP
.RS 4
\fIptr\fP The raw pointer held by the shared_ptr 
.RE
.PP


.SH "Author"
.PP 
Generated automatically by Doxygen for cereal from the source code\&.