Issue 18303: C++ shared member representation breaks safety mechanisms of the struct containing it (dds-xtypes-rtf) Source: PrismTech (Mr. Erik Hendriks, erik.hendriks(at)prismtech.com) Nature: Revision Severity: Significant Summary: 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 could reason why to make this one exception for shared pointers, which will make it much harder to predict the struct's behaviour. Resolution: Revised Text: Actions taken: December 12, 2012: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 12 Dec 2012 08:22:46 -0500 To: Subject: Issue/Bug Report X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== ******************************************************************************* Name: Erik Hendriks Employer: PrismTech mailFrom: erik.hendriks@prismtech,com Terms_Agreement: I agree Specification: Extensible and Dynamic Topic Types for DDS Section: 7.5.1.2.3.2 FormalNumber: ptc/2012-03-26 Version: 1.0 Doc_Year: 2012 Doc_Month: February Doc_Day: Day Page: 114 Title: C++ shared member representation breaks safety mechanisms of the struct containing it Nature: Revision Severity: Significant CODE: 3TMw8 B1: Report Issue Description: 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 could reason why to make this one exception for shared pointers, which will make it much harder to predict the struct's behaviour.