Issue 674: Multiple inheritance of C++ Servants is ill-defined (cxx_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Please find example/discussion in corresponding archive file Resolution: closed and resolved Revised Text: Add the following to the end of section 1.36.6 of formal/99-07-41: For interfaces which inherit from one or more base interfaces, the generated POA skeleton class uses virtual inheritance: // IDL interface A { ... }; interface B : A { ... }; interface C : A { ... }; interface D : B, C { ... }; // C++ class POA_A : public virtual PortableServer::ServantBase { ... }; class POA_B : public virtual POA_A { ... }; class POA_C : public virtual POA_A { ... }; class POA_D : public virtual POA_B, public virtual POA_A { ... }; This guarantees that the POA skeleton class inherits only one version of each operation, and also allows optional inheritance of implementations. In this example, the implementation of interface B reuses the implementation of interface A: // C++ class A_impl: public virtual POA_A { ... }; class B_impl: public virtual POA_B, public virtual A_impl {}; For interfaces which inherit from an abstract interface, the POA skeleton class is also virtually derived directly from the abstract interface class, but with protected access: // IDL abstract interface A { ... }; interface B : A { ... }; // C++ class A { ... }; class POA_B : public virtual PortableServer::ServantBase, protected virtual A { ... }; The abstract interface is inherited with protected access to prevent accidental conversion of the POA skeleton pointer to an abstract interface reference, for ORBs which implement object references as pointers. This also allows implementation classes and valutypes to share an implementation of the abstract interface: // IDL valuetype V : supports A { ... }; // C++ class MyA : virtual A { ... }; class MyB : public virtual POA_B, protected virtual MyA { ... }; class MyV : public virtual V, public virtual MyA { ... }; Actions taken: August 11, 1997: received issue May 12, 1998: issue moved from port-rtf to cxx_revision June 13, 2000: closed issue Discussion: End of Annotations:===== Return-Path: X-Sender: frantz@nashome1.beasys.com Date: Mon, 11 Aug 1997 15:43:28 -0400 To: port-rtf@omg.org, issues@omg.org From: Dan Frantz Subject: POA issues Cc: frantz@beasys.com Issues for the Portability Task Force. 7. Summary: Multiple inheritance of C++ Servants is ill- defined. Discussion: Consider the IDL: interface A {}; interface B {}; interface C : A, B; The mappings for A and B are: class POA_A : ServantBase; class POA_B : ServantBase; What is the mapping for C? class POA_C : POA_A, POA_B, ServantBase; Do the multiple ServantBase implementations cause collisions? ---------------------------------------------------------------------- Dan Frantz BEA Systems, Inc Voice: +1 603 881 2272 Sender: jon@floorboard.com Message-ID: <380CB368.CFC0527A@floorboard.com> Date: Tue, 19 Oct 1999 11:07:36 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Steve Vinoski CC: cxx_revision@omg.org Subject: Re: C++ RTF Vote 1 References: <4.1.19991019035709.00dc8100@mail.boston.iona.ie> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ^4R!!W&Zd9)e(e9!JI!! Steve Vinoski wrote: > > C++ RTF members, > > Please see . This C++ > RTF > vote is made up of the proposed resolutions that Michi posted a few > months > ago, and where appropriate it also reflects some of the email > discussion > that followed his postings. > > Please send your votes on these issues no later than 5pm Pacific > time on > Tuesday, October 26, 1999. You can either email me directly or post > your > votes to this mailing list. > > You can find the C++ RTF membership list at > > . > The only change to this list that I am aware of is that I believe > Ian > Pepper no longer works at ApTest and has no RTF replacement. If I am > in > error here I'm sure Ian will let us know. :-) Floorboard votes yes on all issues, except 674. The resolution text states: "... then class CImpl implementing interface C should be declared as follows:" It should say: "... then class CImpl implementing interface C could be declared as follows:" since an implementation of C need not inherit implementations of A & B, but can provide its own implementation of those interfaces instead. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@floorboard.com Message-ID: <3855E705.B5069FD6@floorboard.com> Date: Mon, 13 Dec 1999 22:43:17 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: cxx_revision@omg.org Subject: Proposal for issues 674, 1535 and 3078 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: MZ'!!g41!!^S_!!dX8e9 Issue 674: Multiple inheritance of C++ Servants is ill-defined Issue 1535: Do POA servant classes need to use virtual inheritance? Another proposal already requires virtual! find it! Issue 3078: 1 of 4 issues with Abstract interfaces Proposal: Add the following to the end of section 1.36.6: For interfaces which inherit from one or more base interfaces, the generated POA skeleton class uses virtual inheritance: // IDL interface A { ... }; interface B : A { ... }; interface C : A { ... }; interface D : B, C { ... }; // C++ class POA_A : public virtual PortableServer::ServantBase { ... }; class POA_B : public virtual POA_A { ... }; class POA_C : public virtual POA_A { ... }; class POA_D : public virtual POA_B, public virtual POA_A { ... }; This guarantees that the POA skeleton class inherits only one version of each operation, and also allows optional inheritance of implementations. In this example, the implementation of interface B reuses the implementation of interface A: // C++ class A_impl: public virtual POA_A { ... }; class B_impl: public virtual POA_B, public virtual A_impl { }; For interfaces which inherit from an abstract interface, the POA skeleton class is also virtually derived directly from the abstract interface class, but with protected access: // IDL abstract interface A { ... }; interface B : A { ... }; // C++ class A { ... }; class POA_B : public virtual PortableServer::ServantBase, protected virtual A { ... }; The abstract interface is inherited with protected access to prevent accidental conversion of the POA skeleton pointer to an abstract interface reference, for ORBs which implement object references as pointers. This also allows implementation classes and valutypes to share an implementation of the abstract interface: // IDL valuetype V : supports A { ... }; // C++ class MyA : virtual A { ... }; class MyB : public virtual POA_B, protected virtual MyA { ... }; class MyV : public virtual V, public virtual MyA { ... }; -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@floorboard.com Message-ID: <385B1538.16845D3D@floorboard.com> Date: Fri, 17 Dec 1999 21:01:44 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Steve Vinoski CC: cxx_revision@omg.org Subject: Re: C++ RTF Vote 2 References: <4.1.19991216144035.01a2f830@mail.boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,7Xd9Za@!!Ji"e9ON9e9 Steve Vinoski wrote: > > C++ RTF members, > > Vote 2 is now available for your perusal at > . There are a HUGE > number of > issues in this vote, so because of that and because of the holiday > season > and vacation days, I've made the voting deadline December 31, > 1999. Because > many of the issues are things that are either already fixed or are > proposed > to be resolved as "close with no change," I also color-coded the > issues so > you know where to focus your energies. > > Many thanks to Jon Biggar for his work in reassembling the issues > list and > submitting many issue resolution proposals over the past week. I > think I > got everything you submitted, Jon, but if I missed anything, we'll > get it > in Vote 3, which I want to hold in early January. (For example, I > didn't > put the fixed-length _var issue in this vote, that will be in Vote 3 > instead.) [ I considered voting no on everything in a fit of schizophrenia, but I figured I'd get mugged at the next meeting I attended, so I won't. :-)] Floorboard votes yes on all issues, with an editorial comment or two: 674: [I found a mistake in my text. :-(] class POA_D : public virtual POA_B, public virtual POA_A { ... }; should be: class POA_D : public virtual POA_B, public virtual POA_C { ... }; ------------------------------------------------------------------------------------ 2496: [I also missed one piece that I intended to add to part 2 changes, that the constructor for concrete factories must be public. Without this change the concrete factory doesn't work.] "For valuetypes that have no operations or initializers, a concrete type-specific factory class is generated whose implementation of the create_for_unmarshal function simply constructs an instance of the OBV_ class for the valuetype using new and the default constructor." should read: "For valuetypes that have no operations or initializers, a concrete type-specific factory class is generated whose implementation of the create_for_unmarshal function simply constructs an instance of the OBV_ class for the valuetype using new and the default constructor. The constructor for a concrete factory is public, not protected." -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org