Issue 1319: C++ Any mapping proposed change (cxx_revision) Source: (, ) Nature: Revision Severity: Summary: Summary: Add the following operation to CORBA::Any: class Any { ... void type(TypeCode_ptr); ... }; This will replace the internal typecode in the any with the specified typecode. If the new typecode is not equivalent to the old typecode (as defined by TypeCode::equivalent), then implementation will raise the BAD_TYPECODE system exception. Resolution: Revised Text: Actions taken: May 12, 1998: received issue February 23, 1999: close issue Discussion: End of Annotations:===== Return-Path: Sender: jon@floorboard.com Date: Tue, 12 May 1998 10:57:13 -0700 From: Jonathan Biggar To: cxx_revision@omg.org, issues@omg.org Subject: C++ Any mapping proposed change As part of the cleanup of the TypeCode comparison and equivalence issue work in the ORB core RTF, I would like to propose the following change for C++ Any: Add the following operation to CORBA::Any: class Any { ... void type(TypeCode_ptr); ... }; This will replace the internal typecode in the any with the specified typecode. If the new typecode is not equivalent to the old typecode (as defined by TypeCode::equivalent), then implementation will raise the BAD_TYPECODE system exception. This allows a programmer to portably create an any that contains an alias typecode of an existing IDL type, for example: // IDL typedef long Foo; // C++ CORBA::Any a; a << (CORBA::Long)0; a.type(_tc_Foo); -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Sender: goldberg@corp.inprise.com Date: Tue, 12 May 1998 11:23:52 -0700 From: Jon Goldberg To: Jonathan Biggar CC: cxx_revision@omg.org, issues@omg.org Subject: Re: C++ Any mapping proposed change References: Jonathan Biggar wrote: > > As part of the cleanup of the TypeCode comparison and equivalence > issue > work in the ORB core RTF, I would like to propose the following > change > for C++ Any: > > Add the following operation to CORBA::Any: > > class Any { > ... > void type(TypeCode_ptr); > ... > }; > > This will replace the internal typecode in the any with the > specified > typecode. If the new typecode is not equivalent to the old typecode > (as > defined by TypeCode::equivalent), then implementation will raise the > BAD_TYPECODE system exception. > > This allows a programmer to portably create an any that contains an > alias typecode of an existing IDL type, for example: > > // IDL > typedef long Foo; > > // C++ > > CORBA::Any a; > > a << (CORBA::Long)0; > > a.type(_tc_Foo); > For this specific example, it seems preferable to have the C++ code actually insert the desired alias type: //C++ a << (Foo) 0; And not go through the steps of replacing the typecode. Is there some larger motivation for this operation that I'm not seeing? take care, Jon Return-Path: Date: Tue, 12 May 1998 12:52:11 -0600 From: Javier Lopez-Martin To: jon@floorboard.com, goldberg@corp.inprise.com Subject: Re: C++ Any mapping proposed change Cc: cxx_revision@omg.org Content-Md5: vIfi1BaFLOwsbBOnR0QfBg== > Jonathan Biggar wrote: > > > > As part of the cleanup of the TypeCode comparison and equivalence > issue > > work in the ORB core RTF, I would like to propose the following > change > > for C++ Any: > > > > Add the following operation to CORBA::Any: > > > > class Any { > > ... > > void type(TypeCode_ptr); > > ... > > }; > > > > This will replace the internal typecode in the any with the > specified > > typecode. If the new typecode is not equivalent to the old > typecode (as > > defined by TypeCode::equivalent), then implementation will raise > the > > BAD_TYPECODE system exception. > > > > This allows a programmer to portably create an any that contains > an > > alias typecode of an existing IDL type, for example: > > > > // IDL > > typedef long Foo; > > > > // C++ > > > > CORBA::Any a; > > > > a << (CORBA::Long)0; > > > > a.type(_tc_Foo); > > > > For this specific example, it seems preferable to have the C++ > code actually insert the desired alias type: > > //C++ > a << (Foo) 0; > > And not go through the steps of replacing the typecode. This wouldn't work, because C++ cannot overload an operation on typedefs. As far as the C++ compiler is concerned, a<<(Foo)0; and a<<(CORBA::Long)0; are exactly the same. > Is there > some larger motivation for this operation that I'm not seeing? This is also useful for replacing the typecode in an any with a more complete version of the same typecode, or with a more compact version of the same typecode. This is currently being discussed in the orb_revision RTF. Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Wed, 13 May 1998 06:52:23 +1000 (EST) From: Michi Henning To: Jon Goldberg cc: Jonathan Biggar , cxx_revision@omg.org, issues@omg.org Subject: Re: C++ Any mapping proposed change On Tue, 12 May 1998, Jon Goldberg wrote: > For this specific example, it seems preferable to have the C++ > code actually insert the desired alias type: > > //C++ > a << (Foo) 0; > > And not go through the steps of replacing the typecode. Is there > some larger motivation for this operation that I'm not seeing? Yes. You cannot overload an operator on typedefs. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Sender: jon@floorboard.com Date: Fri, 17 Jul 1998 19:21:42 -0700 From: Jonathan Biggar To: cxx_revision@omg.org Subject: Proposal for Issue 1319 Here is the first of three proposals I would like the C++ RTF to consider in time for publication in CORBA 2.3: As part of the cleanup of the TypeCode comparison and equivalence issue work in the ORB core RTF, I would like to propose the following change for C++ Any: Add the following operation to CORBA::Any: class Any { ... void type(TypeCode_ptr); ... }; This will replace the internal typecode in the any with the specified typecode. If the new typecode is not equivalent to the old typecode (as defined by TypeCode::equivalent, a new operation added by the ORB core RTF), then the implementation will raise the BAD_TYPECODE system exception. This allows a programmer to portably create an any that contains an alias typecode of an existing IDL type, for example: // IDL typedef long Foo; // C++ CORBA::Any a; a << (CORBA::Long)0; a.type(_tc_Foo); Rational: Because the C++ language mapping maps IDL typedefs to C++ typedefs, overloaded inserter and extractor operators for IDL typedefs cannot be generated by the IDL compiler, due to C++ overloading ambiguity problems. However, there are application domains where being able to distinguish between IDL typedefs in an any is important, for example: // IDL typedef double length; typedef double mass; typedef double time; Without this proposal, there is no portable way to insert a double into an any and make sure that it has the TypeCode associated with one of the above types. This can cause portability problems with other language mappings. In particular, Ada maps IDL typedefs to new types that are considered distinct by the Ada compiler. This means that an Ada program can distinguish between values of the above types in an any. But if an Ada program is expecting an any containing one of these TypeCodes, a C++ program cannot interoperate with it, because it cannot generate an any containing the proper TypeCode. For more information on the new TypeCode::equivalent operation proposal, see the archive for OMG Issue #665. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Fri, 17 Jul 1998 23:34:58 -0700 From: "Jon Goldberg" To: Jonathan Biggar CC: cxx_revision@omg.org Subject: Re: Proposal for Issue 1319 References: Hi- I guess this one is fine with me. I'm assuming the description of this operation will say the implementation is responsible for duplicating the given typecode as currently is written for the Any ctor in CORBA 2.2 section 20.16.6. On the other hand, the example you give below could also be satisfied (as in CORBA 2.2) by: // IDL typedef long Foo; // C++ CORBA::Any a; a.replace(_tc_Foo, new CORBA::Long(0), TRUE); Since the current spec is a bit hazy about the meaning of the value parameter passed to TypeCode::replace, your suggested modification may be the cleanest way to go. -Jon Jonathan Biggar wrote: > > Here is the first of three proposals I would like the C++ RTF to > consider in time for publication in CORBA 2.3: > > As part of the cleanup of the TypeCode comparison and equivalence > issue > work in the ORB core RTF, I would like to propose the following > change > for C++ Any: > > Add the following operation to CORBA::Any: > > class Any { > ... > void type(TypeCode_ptr); > ... > }; > > This will replace the internal typecode in the any with the > specified > typecode. If the new typecode is not equivalent to the old typecode > (as > defined by TypeCode::equivalent, a new operation added by the ORB > core > RTF), then the implementation will raise the BAD_TYPECODE system > exception. > > This allows a programmer to portably create an any that contains an > alias typecode of an existing IDL type, for example: > > // IDL > typedef long Foo; > > // C++ > > CORBA::Any a; > > a << (CORBA::Long)0; > > a.type(_tc_Foo); > > Rational: Because the C++ language mapping maps IDL typedefs to C++ > typedefs, overloaded inserter and extractor operators for IDL > typedefs > cannot be generated by the IDL compiler, due to C++ overloading > ambiguity problems. However, there are application domains where > being > able to distinguish between IDL typedefs in an any is important, for > example: > > // IDL > typedef double length; > typedef double mass; > typedef double time; > > Without this proposal, there is no portable way to insert a double > into > an any and make sure that it has the TypeCode associated with one of > the > above types. This can cause portability problems with other > language > mappings. In particular, Ada maps IDL typedefs to new types that > are > considered distinct by the Ada compiler. This means that an Ada > program > can distinguish between values of the above types in an any. But if > an > Ada program is expecting an any containing one of these TypeCodes, a > C++ > program cannot interoperate with it, because it cannot generate an > any > containing the proper TypeCode. > > For more information on the new TypeCode::equivalent operation > proposal, > see the archive for OMG Issue #665. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Sat, 18 Jul 1998 09:27:43 -0400 To: Jonathan Biggar From: Steve Vinoski Subject: Re: Proposal for Issue 1319 Cc: cxx_revision@omg.org At 07:21 PM 7/17/98 -0700, Jonathan Biggar wrote: >Here is the first of three proposals I would like the C++ RTF to >consider in time for publication in CORBA 2.3: > >As part of the cleanup of the TypeCode comparison and equivalence issue >work in the ORB core RTF, I would like to propose the following change >for C++ Any: > >Add the following operation to CORBA::Any: > >class Any { > ... > void type(TypeCode_ptr); > ... >}; > >This will replace the internal typecode in the any with the specified >typecode. If the new typecode is not equivalent to the old typecode (as >defined by TypeCode::equivalent, a new operation added by the ORB core >RTF), then the implementation will raise the BAD_TYPECODE system >exception. IONA votes to adopt this proposed change. --steve Return-Path: Sender: jon@floorboard.com Date: Sat, 18 Jul 1998 09:33:31 -0700 From: Jonathan Biggar To: cxx_revision@omg.org Subject: Proposals for 1319 & 1626 I suppose it goes without saying that Floorboard votes YES on both of these proposals. :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Sender: jon@floorboard.com Date: Sat, 18 Jul 1998 09:32:33 -0700 From: Jonathan Biggar To: Jon Goldberg CC: cxx_revision@omg.org Subject: Re: Proposal for Issue 1319 References: <35B04212.C6125D1B@inprise.com> Jon Goldberg wrote: > > Hi- > > I guess this one is fine with me. I'm assuming the > description of this operation will say the implementation > is responsible for duplicating the given typecode as currently > is written for the Any ctor in CORBA 2.2 section 20.16.6. Good comment. Yes, the new overloaded type() function will duplicate the TypeCode argument. > On the other hand, the example you give below could also > be satisfied (as in CORBA 2.2) by: > > // IDL > typedef long Foo; > > // C++ > > CORBA::Any a; > a.replace(_tc_Foo, new CORBA::Long(0), TRUE); > > Since the current spec is a bit hazy about the meaning of > the value parameter passed to TypeCode::replace, your suggested > modification may be the cleanest way to go. I agree that this is a possible approach, but we certainly all agree that forcing the programmer to use a non-type safe interface just to get aliases into the TypeCode is a bad idea. -- vJon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Sat, 18 Jul 1998 13:23:20 -0400 To: Jonathan Biggar From: Steve Vinoski Subject: Re: Proposal for Issue 1319 Cc: cxx_revision@omg.org References: <35B04212.C6125D1B@inprise.com> At 09:32 AM 7/18/98 -0700, Jonathan Biggar wrote: >Jon Goldberg wrote: >> On the other hand, the example you give below could also >> be satisfied (as in CORBA 2.2) by: >> >> // IDL >> typedef long Foo; >> >> // C++ >> >> CORBA::Any a; >> a.replace(_tc_Foo, new CORBA::Long(0), TRUE); > >I agree that this is a possible approach, but we certainly all agree >that forcing the programmer to use a non-type safe interface just to get >aliases into the TypeCode is a bad idea. I think JonG's approach would require standardizing what the void* argument means -- ugh. Several RTFs back (perhaps the C++ 1.1 RTF) we decided that there was simply no way we would ever agree on what the void* should actually be assumed to point to for each IDL type, and so we intentionally left it unspecified. We knew it left a portability hole, but we agreed then to leave it that way. I would therefore rather maintain the status quo with respect to the void* and go with JonB's much simpler approach. --steve Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Sun, 19 Jul 1998 07:38:13 +1000 (EST) From: Michi Henning To: Steve Vinoski cc: Jonathan Biggar , cxx_revision@omg.org Subject: Re: Proposal for Issue 1319 On Sat, 18 Jul 1998, Steve Vinoski wrote: > I think JonG's approach would require standardizing what the void* argument > means -- ugh. Several RTFs back (perhaps the C++ 1.1 RTF) we decided that > there was simply no way we would ever agree on what the void* should > actually be assumed to point to for each IDL type, and so we intentionally > left it unspecified. We knew it left a portability hole, but we agreed then > to leave it that way. I would therefore rather maintain the status quo with > respect to the void* and go with JonB's much simpler approach. I fully agree. I'm still hoping that one of these days, we can deprecate the void * functions -- they are effectively useless to anyone wanting to write portable code. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Sun, 19 Jul 1998 07:47:52 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: cxx_revision@omg.org Subject: Re: Proposal for Issue 1319 On Fri, 17 Jul 1998, Jonathan Biggar wrote: > Add the following operation to CORBA::Any: > > class Any { > ... > void type(TypeCode_ptr); > ... > }; DSTC votes yes to accept this change. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Sat, 18 Jul 1998 17:11:39 -0700 From: "Jon Goldberg" To: Michi Henning CC: jon@floorboard.com, cxx_revision@omg.org Subject: Re: Proposal for Issue 1319 References: As does Inprise. -Jon Michi Henning wrote: > > On Fri, 17 Jul 1998, Jonathan Biggar wrote: > > > Add the following operation to CORBA::Any: > > > > class Any { > > ... > > void type(TypeCode_ptr); > > ... > > }; > > DSTC votes yes to accept this change. > > Cheers, > > > Michi. > > > > ------------------------------------------------------------------------ > > Part.001 Name: Part.001 > Type: Plain Text (text/plain) Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Fri, 24 Jul 1998 16:44:45 -0400 To: cxx_revision@omg.org From: Steve Vinoski Subject: Re: We need votes!!!!!!! References: <9807241648.AA06909@jam.tid.es> At 08:56 AM 7/24/98 -0700, Jonathan Biggar wrote: >Ok, here's the new scoreboard: > >Issue 1319: > Yes: 6 (Floorboard, DSTC, HP, IONA, Inprise, Telefonica) > No: 0 > NV: 4 > >Issue 1626: > Yes: 6 (Floorboard, DSTC, HP, IONA, Inprise, Telefonica) > No: 0 > NV: 4 Because we have ten RTF members, once a proposal has six votes, it passes. This means that 1319 and 1626 have been adopted. Just a reminder: the voting deadline is Monday July 27th at 5:00pm EDT. I will then get a revised C++ document reflecting the adopted proposals out to this RTF sometime on Tuesday, as early as possible, and it will need a very quick review from you guys because it is due to the OMG on Wednesday. Sorry for the short timeframes, but with all the other RTFs in progress and the time needed to vet these proposals, it's the best we could do. --steve Date: Sun, 21 Feb 1999 09:19:58 +1000 (EST) From: Michi Henning To: C++ Revision Task Force Subject: Proposal for 1319 Organization: Triodia Technologies Mark 1319 as closed -- we have the type() modifier now. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html