Issue 16565: IDL mapping for non-trivial struct fields (dds-psm-cxx-ftf) Source: Northrop Grumman (Mr. Trent Nadeau, trent.nadeau(at)ngc.com) Nature: Uncategorized Issue Severity: Summary: The “representative” example in Section 8.2 is not very “representative”. For example, everything in the struct can be trivially returned by value (either a basic type or a pointer) with no impact on performance. If, instead, there were a substructure that was large and/or deeply nested, this example seems to break down. For example: typedef sequence<long, 1000000> HugeLongSeq; // 4 MB struct LargeStruct { long id; HugeLongSeq mySeq; }; struct RadarTrack { string id; long x; long y; long z; //@optional sequence<octet> plot; //@shared LargeStruct myLargeMember; // new field }; According to Section 7.4, the return value of the accessor for myLargeMember would either return by value or const reference. This would cause two copies (one for return value of getter and another for setter) of 4 MB of data in order to change one element of LargeStruct::mySeq in the instance. I believe that use cases like this require accessors that return by non-const reference if the generated code is to be at all efficient. On page 17 of the Beta 1 spec, there is already use of this pattern for the non-const accessors on the History class (where it probably makes less sense since the types are small). I believe that this pattern should also be used for generated code where many large types can be arbitrarily nested. Resolution: Revised Text: Actions taken: September 23, 2011: recived issue Discussion: End of Annotations:===== m: "Nadeau, Trent (ES)" To: "dds-psm-cxx-ftf@omg.org" Subject: IDL mapping for non-trivial struct fields Thread-Topic: IDL mapping for non-trivial struct fields Thread-Index: Acx59hVcu1zhuDWyRdmz789DQb74/A== Date: Fri, 23 Sep 2011 13:38:32 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.223.82.118] The .representative. example in Section 8.2 is not very .representative.. For example, everything in the struct can be trivially returned by value (either a basic type or a pointer) with no impact on performance. If, instead, there were a substructure that was large and/or deeply nested, this example seems to break down. For example: typedef sequence HugeLongSeq; // 4 MB struct LargeStruct { long id; HugeLongSeq mySeq; }; struct RadarTrack { string id; long x; long y; long z; //@optional sequence plot; //@shared LargeStruct myLargeMember; // new field }; According to Section 7.4, the return value of the accessor for myLargeMember would either return by value or const reference. This would cause two copies (one for return value of getter and another for setter) of 4 MB of data in order to change one element of LargeStruct::mySeq in the instance. I believe that use cases like this require accessors that return by non-const reference if the generated code is to be at all efficient. On page 17 of the Beta 1 spec, there is already use of this pattern for the non-const accessors on the History class (where it probably makes less sense since the types are small). I believe that this pattern should also be used for generated code where many large types can be arbitrarily nested. Trent Nadeau Software Engineer - Teton SNA Northrop Grumman Electronic Systems 1550 W. Nursery Rd. MS C550 Baltimore, MD 21203 Phone: (410) 765-4033 Fax: (410) 981-6953