In the cpp-sample "datalayer.realtime" you can build two executables (owner, user) that exchange data via shared memory.
The 'owner' is using the datalayer API functions "createMemorySync(...)" and "deleteMemorySync(...)".
The 'user' is using the datalayer API functions "openMemory(...)" and "closeMemory(...)".
The first parameter of these functions is a reference to a std::shared_ptr (IN/OUT parameter).
The functions "createMemorySync(...)" and "openMemory(...)" setting the stored pointer of the smart pointer to a valid memory address (shared memory for data exchange).
The functions "deleteMemorySync(...)" and "closeMemory(...)" resetting the stored pointer to nullptr.
BUT from the application point of view the given std::shared_ptr to the latter functions might by a copy. This is excactly done in the 'user' and 'owner' example code. This leads to the following error situation. A copy of the std::shared_ptr has been reset, calling its destruction is perfectly fine. BUT the remaining copies still hold the pointer to shared memory. When the destructor of the last copy is called a segmentation fault occurs. Dereferencing such a smart pointer copy is also a bad idea.
These datalayer API functions ignore the main concept of smart pointers (take ownership and manage lifecycle).
In the cpp-sample "datalayer.realtime" you can build two executables (owner, user) that exchange data via shared memory. The 'owner' is using the datalayer API functions "createMemorySync(...)" and "deleteMemorySync(...)". The 'user' is using the datalayer API functions "openMemory(...)" and "closeMemory(...)". The first parameter of these functions is a reference to a std::shared_ptr (IN/OUT parameter). The functions "createMemorySync(...)" and "openMemory(...)" setting the stored pointer of the smart pointer to a valid memory address (shared memory for data exchange). The functions "deleteMemorySync(...)" and "closeMemory(...)" resetting the stored pointer to nullptr. BUT from the application point of view the given std::shared_ptr to the latter functions might by a copy. This is excactly done in the 'user' and 'owner' example code. This leads to the following error situation. A copy of the std::shared_ptr has been reset, calling its destruction is perfectly fine. BUT the remaining copies still hold the pointer to shared memory. When the destructor of the last copy is called a segmentation fault occurs. Dereferencing such a smart pointer copy is also a bad idea. These datalayer API functions ignore the main concept of smart pointers (take ownership and manage lifecycle).