Issue 3380: Constructor for structures? (cxx_revision) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: The mapping for user exceptions and structures is identical, except for one thing: user exceptions have an additional constructor with one parameter for each member, so I can construct and throw the exception with a single throw statement. However, structures are second-class citizens: I can't instantiate and initialize a structure at the same time. (Well, at least not in general, because static initialization only works for aggregates and, at any rate, I can only instantiate and initialize with compile-time constants.) So, why don't we add the same constructor to the mapping for structures? It seems inconsistent to have one mapping for structures and a slightly different one for exceptions, when in fact they both could be the same. Resolution: Revised Text: Actions taken: March 1, 2000: received issue Discussion: deferred in June 2011 to the next RTF End of Annotations:===== Sender: jbiggar@corvette.floorboard.com Message-ID: <38B5A853.66702F5A@floorboard.com> Date: Thu, 24 Feb 2000 13:53:23 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org, cxx_revision@omg.org Subject: Issue with valuetypes & inout/out parameters Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: !5Td9R:Me9m_nd9?K;!! The CORBA 2.3 C++ specification, section 1.22 states that valuetypes passed as in parameters to an invocation of an object are copied, even if the object is collocated with the caller. It does not make this statement for inout or out parameters (or return results), which strongly suggests that valuetype copying is not necessary. In fact, the text for valuetype inout parameters strongly suggests that copying is not performed. I think this is wrong and inout & out valuetypes should be copied as well (inout parameters should be copied before and after the invocation, while out and return values should be copied after the invocation completes.) Without the copies, call transparency will be broken and the client can distinguish between a local and a remote call. For example: // IDL valuetype V { public short s; }; interface I { void op(inout V a_v); }; // C++ client code V_var my_v = get_a_v_from_somewhere(); my_v->s(1); CORBA::add_ref(my_v); V_var my_v_also = v; I_var my_i = get_an_i_from_somewhere(); i->op(my_v_also); assert(my_v->s() != my_v_also->s()); // C++ server code void MyI_impl::op(V *&a_v) { a_v->s(2); } If inout valuetypes are not copied, then when the call is remote, the assertion succeeds, but when the call is collocated the assertion fails. The same argument can be made that inout, out and return valuetype parameters must be copied after the invocation completes, otherwise if the server code retains a reference (via add_ref()) to the valuetype, the client and server can tell if the call was collocated or not. Proposal: Rewrite the paragraph in section 1.22 about valuetype parameters from: "For in valuetypes, the callee shall receive a copy of each valuetype argument passed to it even if the caller and callee are collocated in the same process. The callee is allowed to invoke operations and modifier functions that modify the state of the valuetype instance, but the state of the caller's copy of that valuetype instance shall not be affected by the callee's state changes. This is required to preserve location transparency for interface operations." to: "For in and inout valuetype parameters, the callee shall receive a copy of each valuetype argument passed to it even if the caller and callee are collocated in the same process. The callee is allowed to invoke operations and modifier functions that modify the state of the valuetype instance, but the state of the caller's copy of that valuetype instance shall not be affected by the callee's state changes. This is required to preserve location transparency for interface operations. For the same reason, inout, out and return result valuetype parameters are copied after the callee completes before they are returned to the caller." -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Jeffrey Mischkinsky Message-Id: <200002250350.TAA25837@wheel.dcn.davis.ca.us> Subject: Re: Issue with valuetypes & inout/out parameters To: jon@floorboard.com (Jonathan Biggar) Date: Thu, 24 Feb 2000 19:50:00 -0800 (PST) Cc: issues@omg.org, cxx_revision@omg.org In-Reply-To: <38B5A853.66702F5A@floorboard.com> from "Jonathan Biggar" at Feb 24, 2000 01:53:23 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: o=#!!@[?!!7pZd9!P3e9 'Jonathan Biggar' writes: > > The CORBA 2.3 C++ specification, section 1.22 states that valuetypes > passed as in parameters to an invocation of an object are copied, > even > if the object is collocated with the caller. It does not make this > statement for inout or out parameters (or return results), which > strongly suggests that valuetype copying is not necessary. In fact, > the > text for valuetype inout parameters strongly suggests that copying > is > not performed. If you look at the general description of valuetype semantics in Ch 5, I think it is quite clear that copying is in fact performed for all orb-mediated calls. See for e.g.: 5.2.4.3 When a instance of the value type is passedas a parameter, an independent copy of the instance is instantiated in the receiving context. that copy is a separate independent entity and there is no explicit or implicit sharing of state. [I picked the phrase "receiving context" to cover the cases of in, inout, out and result. The direction doesn't matter.] Section 5.2 , first several paragraphs say that ORB mediated calls guarantee copy semantics, whereas non orb-mediated calls don't. So I agree that your interpretation is the intended one. I'm not sure that you have to go to quite the detail that you propose, but if it is felt necessary then it may be better to place more detailed language in the Ch 5, which applies to all language mappings, not just c++. jeff > I think this is wrong and inout & out valuetypes should be copied as > well (inout parameters should be copied before and after the > invocation, > while out and return values should be copied after the invocation > completes.) Without the copies, call transparency will be broken > and > the client can distinguish between a local and a remote call. For > example: > > // IDL > valuetype V { > public short s; > }; > > interface I { > void op(inout V a_v); > }; > > // C++ client code > > V_var my_v = get_a_v_from_somewhere(); > > my_v->s(1); > CORBA::add_ref(my_v); > > V_var my_v_also = v; > I_var my_i = get_an_i_from_somewhere(); > > i->op(my_v_also); > > assert(my_v->s() != my_v_also->s()); > > // C++ server code > > void MyI_impl::op(V *&a_v) > { > a_v->s(2); > } > > If inout valuetypes are not copied, then when the call is remote, > the > assertion succeeds, but when the call is collocated the assertion > fails. The same argument can be made that inout, out and return > valuetype parameters must be copied after the invocation completes, > otherwise if the server code retains a reference (via add_ref()) to > the > valuetype, the client and server can tell if the call was collocated > or > not. > > Proposal: > > Rewrite the paragraph in section 1.22 about valuetype parameters > from: > > "For in valuetypes, the callee shall receive a copy of each > valuetype > argument passed to it even if the caller and callee are collocated > in > the same process. The callee is allowed to invoke operations and > modifier functions that modify the state of the valuetype instance, > but > the state of the caller's copy of that valuetype instance shall not > be > affected by the callee's state changes. This is required to preserve > location transparency for interface operations." > > to: > > "For in and inout valuetype parameters, the callee shall receive a > copy > of each valuetype argument passed to it even if the caller and > callee > are collocated in the same process. The callee is allowed to invoke > operations and modifier functions that modify the state of the > valuetype > instance, but the state of the caller's copy of that valuetype > instance > shall not be affected by the callee's state changes. This is > required to > preserve location transparency for interface operations. For the > same > reason, inout, out and return result valuetype parameters are copied > after the callee completes before they are returned to the caller." > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: Paul Kyzivat To: cxx_revision@omg.org Subject: RE: Issue with valuetypes & inout/out parameters Date: Fri, 25 Feb 2000 11:15:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: =%>!!Pk'!!Y_?!!#/od9 This is getting out of hand! Before long we will be requiring that collocated calls all be marshalled! I think the copying of valuetypes in collocated calls is in general the wrong thing to do. I hesitate to bring this up, but if it is so important for valuetypes, why not for other types as well? Consider: // IDL typedef sequence Longs; interface Foo { void bar(inout Longs a, inout Longs b); }; If I call bar passing a single instance of Longs as both arguments, I will most likely get different results depending on whether the call is collocated or not. But the cost/benefit tradeoff does not justify copying to prevent this. And I don't think it does so for valuetypes either. I want collocated calls to come close to regular local calls in performance. This should simply be a recognized limitation. Paul > -----Original Message----- > From: Jonathan Biggar [mailto:jon@floorboard.com] > Sent: Thursday, February 24, 2000 4:53 PM > To: issues@omg.org; cxx_revision@omg.org > Subject: Issue with valuetypes & inout/out parameters > > > The CORBA 2.3 C++ specification, section 1.22 states that valuetypes > passed as in parameters to an invocation of an object are copied, > even > if the object is collocated with the caller. It does not make this > statement for inout or out parameters (or return results), which > strongly suggests that valuetype copying is not necessary. > In fact, the > text for valuetype inout parameters strongly suggests that copying > is > not performed. > > I think this is wrong and inout & out valuetypes should be copied as > well (inout parameters should be copied before and after the > invocation, > while out and return values should be copied after the invocation > completes.) Without the copies, call transparency will be broken > and > the client can distinguish between a local and a remote call. For > example: > > // IDL > valuetype V { > public short s; > }; > > interface I { > void op(inout V a_v); > }; > > // C++ client code > > V_var my_v = get_a_v_from_somewhere(); > > my_v->s(1); > CORBA::add_ref(my_v); > > V_var my_v_also = v; > I_var my_i = get_an_i_from_somewhere(); > > i->op(my_v_also); > > assert(my_v->s() != my_v_also->s()); > > // C++ server code > > void MyI_impl::op(V *&a_v) > { > a_v->s(2); > } > > If inout valuetypes are not copied, then when the call is remote, > the > assertion succeeds, but when the call is collocated the assertion > fails. The same argument can be made that inout, out and return > valuetype parameters must be copied after the invocation completes, > otherwise if the server code retains a reference (via > add_ref()) to the > valuetype, the client and server can tell if the call was > collocated or > not. > > Proposal: > > Rewrite the paragraph in section 1.22 about valuetype parameters > from: > > "For in valuetypes, the callee shall receive a copy of each > valuetype > argument passed to it even if the caller and callee are collocated > in > the same process. The callee is allowed to invoke operations and > modifier functions that modify the state of the valuetype > instance, but > the state of the caller's copy of that valuetype instance shall not > be > affected by the callee's state changes. This is required to preserve > location transparency for interface operations." > > to: > > "For in and inout valuetype parameters, the callee shall > receive a copy > of each valuetype argument passed to it even if the caller and > callee > are collocated in the same process. The callee is allowed to invoke > operations and modifier functions that modify the state of > the valuetype > instance, but the state of the caller's copy of that > valuetype instance > shall not be affected by the callee's state changes. This is > required to > preserve location transparency for interface operations. For the > same > reason, inout, out and return result valuetype parameters are copied > after the callee completes before they are returned to the caller." > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > Sender: jbiggar@corvette.floorboard.com Message-ID: <38B6F546.8B082BA3@floorboard.com> Date: Fri, 25 Feb 2000 13:33:58 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Mischkinsky CC: issues@omg.org, cxx_revision@omg.org Subject: Re: Issue with valuetypes & inout/out parameters References: <200002250350.TAA25837@wheel.dcn.davis.ca.us> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 0Gdd9d'ed93`Ee9em%!! Jeffrey Mischkinsky wrote: > If you look at the general description of valuetype semantics in Ch > 5, I > think it is quite clear that copying is in fact performed for all > orb-mediated > calls. > > See for e.g.: > 5.2.4.3 When a instance of the value type is passedas a parameter, > an > independent copy of the instance is instantiated in the receiving > context. > that copy is a separate independent entity and there is no > explicit or > implicit sharing of state. > > [I picked the phrase "receiving context" to cover the cases of in, > inout, > out and result. The direction doesn't matter.] > > Section 5.2 , first several paragraphs say that ORB mediated calls > guarantee copy semantics, whereas non orb-mediated calls don't. > > So I agree that your interpretation is the intended one. > I'm not sure that you have to go to quite the detail that you > propose, but > if it is felt necessary then it may be better to place more detailed > language in the Ch 5, which applies to all language mappings, not > just c++. I agree with you that the Core Chapter 5 quote is clear. The C++ mapping is the part that is unclear, since it does strongly imply that only 'in' valuetypes are copied. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org