DDSXTY12 — C++ shared member representation breaks safety mechanisms of the struct containing it

By clearly stating that a shared member must map onto a plain pointer, not a _var type or other smart pointer you are breaking the safety mechanisms that the C++ struct had inherently built into it, since on destruction or re-assignment the shared pointer may now leak away. The whole point of using _var types or other smart types was to prevent this from happening. I see no good reason why to make this one exception for shared pointers, which will make it much harder to predict the struct's behaviour.

Define the language binding for shared members in C and C++

Shared members are currently mapped to plain pointers in C and C++. This mapping prevents safety mechanisms, such as shared pointers in C++, from being used to automatically handle the memory management of these members. We are redefining the language mapping to add in these safety mechanisms and to allow the memory to be handled differently on the sending and receiving sides of an application.