Issue 16564: optional support (dds-psm-cxx-ftf) Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl) Nature: Uncategorized Issue Severity: Summary: DDS PSM does expose dds::core::optional to the end user when he uses @optional. At some moment we also have this available at the CCM level, what about using something that is not tied to DDS in the user defined type? Is there nothing in STL that can be used for this? Resolution: Revised Text: Actions taken: September 23, 2011: received issue Discussion: End of Annotations:===== rus-Scanned: by XS4ALL Virus Scanner Date: Fri, 23 Sep 2011 15:24:05 +0200 From: Johnny Willemsen Reply-To: jwillemsen@remedy.nl Organization: Remedy IT User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110907 Thunderbird/6.0.2 To: "dds-psm-cxx-ftf@omg.org" Subject: optional support Hi, The DDS PSM does expose dds::core::optional to the end user when he uses @optional. At some moment we also have this available at the CCM level, what about using something that is not tied to DDS in the user defined type? Is there nothing in STL that can be used for this? Johnny From: Richard Warren To: "jwillemsen@remedy.nl" CC: "dds-psm-cxx-ftf@omg.org" Date: Fri, 23 Sep 2011 17:58:05 -0700 Subject: Re: optional support Thread-Topic: optional support Thread-Index: Acx6VQTwwvnodgRsQEuwHPbNOMWQRA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8O0vwxc005136 Johnny, I liked dds::core::optional, but I agree it's probably better to eliminate dependencies on OMG-specific types in generated code whenever possible. There's boost::optional and there's Nullable in .Net, but there doesn't seem to be any equivalent in STL. Too bad. There's std::scoped_pointer; that seems to be the closest thing. Otherwise a raw pointer. Have a safe trip home, - Rick -- Rick Warren Director of Technology Solutions RTI Tel 626.584.0141 rick.warren@rti.com www.rti.com RTI - The Global Leader in DDS On Sep 23, 2011, at 9:24 AM, Johnny Willemsen wrote: > Hi, > > The DDS PSM does expose dds::core::optional to the end user when he uses > @optional. At some moment we also have this available at the CCM level, > what about using something that is not tied to DDS in the user defined > type? Is there nothing in STL that can be used for this? > > Johnny > Cc: "jwillemsen@remedy.nl" , "dds-psm-cxx-ftf@omg.org" X-Mailer: iPhone Mail (8L1) From: Angelo Corsaro Subject: Re: optional support Date: Sat, 24 Sep 2011 07:10:15 +0200 To: Richard Warren X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8O5Bhsn022170 Hello guys, I am OK looking for a standard replacement on the C++ standard library. But I am strongly against raw pointers. BTW, the option type as currently defined is a template and does not require any specific code generation. Cheers, Angelo -- Angelo Corsaro, PhD Chief Technology Officer PrismTech On 24 sept. 2011, at 02:58, Richard Warren wrote: > Johnny, > I liked dds::core::optional, but I agree it's probably better to eliminate dependencies on OMG-specific types in generated code whenever possible. > > There's boost::optional and there's Nullable in .Net, but there doesn't seem to be any equivalent in STL. Too bad. There's std::scoped_pointer; that seems to be the closest thing. Otherwise a raw pointer. > > Have a safe trip home, > - Rick > > -- > Rick Warren > Director of Technology Solutions > RTI > Tel 626.584.0141 > rick.warren@rti.com > www.rti.com > > RTI - The Global Leader in DDS > > On Sep 23, 2011, at 9:24 AM, Johnny Willemsen wrote: > >> Hi, >> >> The DDS PSM does expose dds::core::optional to the end user when he uses >> @optional. At some moment we also have this available at the CCM level, >> what about using something that is not tied to DDS in the user defined >> type? Is there nothing in STL that can be used for this? >> >> Johnny >> > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; bh=TrsyWqp4VsUamofsCi0hDsuc3oFG2sxl8uUuP2vtC24=; b=RIrdO+RA1lbDR8YCla3POni2qac6rjdI6dcxqVpq8Qq+tP0N0r56R4b4U1ps+zrXLk cqCya1hZPlNvii5EngSben62hBISpgQ4iPZRbJx4ROLI+PHNQJQVSIOKVsEaDuQWd84W s/1hgDoeKHWY/8oO5fYk8qOgknefxT9s2udL4= Sender: Johnny Willemsen Cc: Richard Warren , "dds-psm-cxx-ftf@omg.org" X-Mailer: iPad Mail (8L1) From: Johnny Willemsen Subject: Re: optional support Date: Sat, 24 Sep 2011 12:01:58 -0400 To: Angelo Corsaro X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8OG1vc1007632 Hi, The shared annotation also maps to a raw pointer. The current proposal maps optional as a dds specific extension, to my idea the mapping of the idl types to c++ should be middleware agnostic. That way we could use optional also at the ccm layer without dds. If this annotation is intended to just be for dds I would like to prefix it with dds to make that clear to the user. Johnjy Op 24 sep. 2011 om 01:10 heeft Angelo Corsaro het volgende geschreven: > Hello guys, > > I am OK looking for a standard replacement on the C++ standard library. But I am strongly against raw pointers. > > BTW, the option type as currently defined is a template and does not require any specific code generation. > > Cheers, > Angelo > > -- > Angelo Corsaro, PhD > Chief Technology Officer > PrismTech > > > On 24 sept. 2011, at 02:58, Richard Warren wrote: > >> Johnny, >> I liked dds::core::optional, but I agree it's probably better to eliminate dependencies on OMspecific types in generated code whenever possible. >> >> There's boost::optional and there's Nullable in .Net, but there doesn't seem to be any equivalent in STL. Too bad. There's std::scoped_pointer; that seems to be the closest thing. Otherwise a raw pointer. >> >> Have a safe trip home, >> - Rick >> >> -- >> Rick Warren >> Director of Technology Solutions >> RTI >> Tel 626.584.0141 >> rick.warren@rti.com >> www.rti.com >> >> RTI - The Global Leader in DDS >> >> On Sep 23, 2011, at 9:24 AM, Johnny Willemsen wrote: >> >>> Hi, >>> >>> The DDS PSM does expose dds::core::optional to the end user when he uses >>> @optional. At some moment we also have this available at the CCM level, >>> what about using something that is not tied to DDS in the user defined >>> type? Is there nothing in STL that can be used for this? >>> >>> Johnny >>> >> From: Richard Warren To: Johnny Willemsen CC: Angelo Corsaro , "dds-psm-cxx-ftf@omg.org" Date: Mon, 26 Sep 2011 09:41:24 -0700 Subject: Re: optional support Thread-Topic: optional support Thread-Index: Acx8ayHZ7BRuLa+9QlK4aVTL1p9j/g== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8QGfIos027431 Johnny, Optional members are currently a DDS-only concept, because they are defined in the DDS-XTypes spec. I would expect that a future refactoring between that spec and IDL (4.x) would make them more widely available. Therefore, we should probably consider an "omg" namespace rather than a "dds" one, if we stick with the template. I think the foundation of the discussion must rest on this point: do we believe it's acceptable for users to have to #include OMG header files in their type definitions? If we really want users to marshall and distribute "their own" data types, which we expect them to use throughout their application, I think the answer must be No. OMG header files will be pulled into the compilation all over their code; it represents a lack of separation of concerns. But if we expect them to use different data types in their applications, and manually "marshall" to OMG-compatible types at the time those types go on the network, then OMG header files are not a big deal, because the inclusions will be limited to the distribution layer of the application. Regards, - Rick -- Rick Warren Director of Technology Solutions RTI Tel 626.584.0141 rick.warren@rti.com www.rti.com RTI - The Global Leader in DDS On Sep 24, 2011, at 9:01 AM, Johnny Willemsen wrote: > Hi, > > The shared annotation also maps to a raw pointer. The current proposal maps optional as a dds specific extension, to my idea the mapping of the idl types to c++ should be middleware agnostic. That way we could use optional also at the ccm layer without dds. If this annotation is intended to just be for dds I would like to prefix it with dds to make that clear to the user. > > Johnjy >