Issue 3603: unspecified criterion for Any extraction (cxx_revision) Source: Cisco Systems (Mr. Paul Kyzivat, pkyzivat(at)cisco.com) Nature: Uncategorized Issue Severity: Summary: The C++ language mapping does not specify what criterion should be used to determine the validity of a typesafe extraction from an Any. The closest it ever comes is the statement in 1.16.3: "In this case, the version of operator>>= for type Long must be able to determine whether the Any truly does contain a value of type Long...". There are two obvious candidates: the equal and equivalent operations of TypeCode. Proposed resolution: Replace the first sentence of 1.16.3: "To allow type-safe retrieval of a value from an any, the mapping provides the following operators for each OMG IDL type T:" with: To allow type-safe retrieval of a value from an Any, the mapping provides an operator>>= for each OMG IDL type T. Each such operator returns a boolean indicating success or failure, and if successful, makes the value of the any available via a user supplied argument. The success of the operation is determined by applying the {equal | equivalent} operation to the typecode of the any and the typecode of the target type. The exact form of operator>>= varies according to the type T as follows: The choice of {equal | equivalent} needs to be discussed. I believe there are valid arguments for each. Resolution: Revised Text: Actions taken: May 9, 2000: received issue Discussion: deferred in June 2011 to the next RTF End of Annotations:===== From: Paul Kyzivat To: "'issues@omg.org'" , "'cxx_revision@omg.org'" Subject: unspecified criterion for Any extraction Date: Tue, 9 May 2000 10:40:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: iD,e9d^3e93@Me9cdod9 The C++ language mapping does not specify what criterion should be used to determine the validity of a typesafe extraction from an Any. The closest it ever comes is the statement in 1.16.3: "In this case, the version of operator>>= for type Long must be able to determine whether the Any truly does contain a value of type Long...". There are two obvious candidates: the equal and equivalent operations of TypeCode. Proposed resolution: Replace the first sentence of 1.16.3: "To allow type-safe retrieval of a value from an any, the mapping provides the following operators for each OMG IDL type T:" with: To allow type-safe retrieval of a value from an Any, the mapping provides an operator>>= for each OMG IDL type T. Each such operator returns a boolean indicating success or failure, and if successful, makes the value of the any available via a user supplied argument. The success of the operation is determined by applying the {equal | equivalent} operation to the typecode of the any and the typecode of the target type. The exact form of operator>>= varies according to the type T as follows: The choice of {equal | equivalent} needs to be discussed. I believe there are valid arguments for each. Paul Sender: jbiggar@corvette.floorboard.com Message-ID: <391857CE.F55DE758@floorboard.com> Date: Tue, 09 May 2000 11:24:14 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: "'issues@omg.org'" , "'cxx_revision@omg.org'" Subject: Re: unspecified criterion for Any extraction References: <9B164B713EE9D211B6DC0090273CEEA926BE7E@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: GT~e9+cE!!#U#e9\^_!! Paul Kyzivat wrote: > > The C++ language mapping does not specify what criterion should be used to > determine the validity of a typesafe extraction from an Any. > > The closest it ever comes is the statement in 1.16.3: > "In this case, the version of operator>>= for type Long must be able to > determine whether the Any truly does contain a value of type Long...". > > There are two obvious candidates: the equal and equivalent operations of > TypeCode. > > Proposed resolution: > > Replace the first sentence of 1.16.3: > > "To allow type-safe retrieval of a value from > an any, the mapping provides the following > operators for each OMG IDL type T:" > > with: > > To allow type-safe retrieval of a value > from an Any, the mapping provides an > operator>>= for each OMG IDL type T. > Each such operator returns a boolean > indicating success or failure, and if > successful, makes the value of the any > available via a user supplied argument. > The success of the operation is determined > by applying the {equal | equivalent} > operation to the typecode of the any and > the typecode of the target type. > > The exact form of operator>>= varies > according to the type T as follows: > > The choice of {equal | equivalent} needs to be discussed. I believe there > are valid arguments for each. My appologies. When I initially wrote up the TypeCode::equivalent proposal, the intention was to clarify that the C++ Any extractors used equivalent, not equal. Extractors must use equivalent, since they cannot be overloaded for IDL typedefs: // IDL struct S { }; typedef S T; maps to: // C++ struct S { }; typedef S T; CORBA::Boolean operator >>=(const CORBA::Any &a, const S *&); an extraction operator cannot be generated for T, since it would be ambiguous in C++. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Paul Kyzivat To: "'cxx_revision@omg.org'" Subject: RE: unspecified criterion for Any extraction Date: Tue, 9 May 2000 17:48:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: WkUd9*_De9U/T!!*mO!! Jon, I was expecting the answer to be "equivalent", but I want to give it a day or so to see if there is any disagreement. Then I will have a related issue to file. Paul > -----Original Message----- > From: Jonathan Biggar [mailto:jon@floorboard.com] > Sent: Tuesday, May 09, 2000 2:24 PM > To: Paul Kyzivat > Cc: 'issues@omg.org'; 'cxx_revision@omg.org' > Subject: Re: unspecified criterion for Any extraction > > > Paul Kyzivat wrote: > > > > The C++ language mapping does not specify what criterion > should be used to > > determine the validity of a typesafe extraction from an Any. > > > > The closest it ever comes is the statement in 1.16.3: > > "In this case, the version of operator>>= for type Long > must be able to > > determine whether the Any truly does contain a value of > type Long...". > > > > There are two obvious candidates: the equal and equivalent > operations of > > TypeCode. > > > > Proposed resolution: > > > > Replace the first sentence of 1.16.3: > > > > "To allow type-safe retrieval of a value from > > an any, the mapping provides the following > > operators for each OMG IDL type T:" > > > > with: > > > > To allow type-safe retrieval of a value > > from an Any, the mapping provides an > > operator>>= for each OMG IDL type T. > > Each such operator returns a boolean > > indicating success or failure, and if > > successful, makes the value of the any > > available via a user supplied argument. > > The success of the operation is determined > > by applying the {equal | equivalent} > > operation to the typecode of the any and > > the typecode of the target type. > > > > The exact form of operator>>= varies > > according to the type T as follows: > > > > The choice of {equal | equivalent} needs to be discussed. I > believe there > > are valid arguments for each. > > My appologies. When I initially wrote up the TypeCode::equivalent > proposal, the intention was to clarify that the C++ Any > extractors used > equivalent, not equal. > > Extractors must use equivalent, since they cannot be > overloaded for IDL > typedefs: > > // IDL > struct S { }; > typedef S T; > > maps to: > > // C++ > struct S { }; > typedef S T; > > CORBA::Boolean operator >>=(const CORBA::Any &a, const S *&); > > an extraction operator cannot be generated for T, since it would be > ambiguous in C++. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > Date: Wed, 10 May 2000 08:01:40 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: "'cxx_revision@omg.org'" Subject: RE: unspecified criterion for Any extraction In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BE83@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: YO!!!p6D!!l%@!!QWCe9 On Tue, 9 May 2000, Paul Kyzivat wrote: > Jon, > > I was expecting the answer to be "equivalent", but I want to give it > a day > or so to see if there is any disagreement. Then I will have a > related issue > to file. No disagreement from me. equivalent() has been the intent all along. Cheers, Michi. X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 10 May 2000 09:49:22 -0400 To: Michi Henning From: Steve Vinoski Subject: RE: unspecified criterion for Any extraction Cc: cxx_revision@omg.org In-Reply-To: References: <9B164B713EE9D211B6DC0090273CEEA926BE83@bos1.noblenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: biI!!ZXp!!?J5!!cF5!! At 08:01 AM 5/10/00 +1000, Michi Henning wrote: On Tue, 9 May 2000, Paul Kyzivat wrote: > Jon, > > I was expecting the answer to be "equivalent", but I want to give it >a day > or so to see if there is any disagreement. Then I will have a >related issue > to file. No disagreement from me. equivalent() has been the intent all along. Agreed. --steve