Issue 1526: Problem with C++ language mapping for OBV (obv-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: 1. The following IDL cannot be translated into C++ code by an IDL compiler for a C++ environment that does not support namespaces: // IDL module M { struct S { boolean b; }; interface I { void op(in S arg); }; value V supports A { }; }; The reason for this is that module M maps to a C++ class when namespaces are not available, and you end up with the following definition loop: POA_M::I must be defined before M::V, since M::V inherits from it M must be defined before POA_M, because POA_M::I depends on M::S but defining M also defines M::V Resolution: Revised Text: Actions taken: June 16, 1998: received issue July 30, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Sender: jon@floorboard.com Date: Mon, 15 Jun 1998 17:54:17 -0700 From: Jonathan Biggar To: obval@omg.org, issues@omg.org Subject: Problem with C++ language mapping for Objects-by-value 1. The following IDL cannot be translated into C++ code by an IDL compiler for a C++ environment that does not support namespaces: // IDL module M { struct S { boolean b; }; interface I { void op(in S arg); }; value V supports A { }; }; The reason for this is that module M maps to a C++ class when namespaces are not available, and you end up with the following definition loop: POA_M::I must be defined before M::V, since M::V inherits from it M must be defined before POA_M, because POA_M::I depends on M::S but defining M also defines M::V -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Mon, 15 Jun 1998 23:31:39 -0400 To: Jonathan Biggar From: Steve Vinoski Subject: Re: Problem with C++ language mapping for Objects-by-value Cc: obval@omg.org, obv-rtf@omg.org, issues@omg.org At 05:54 PM 6/15/98 -0700, Jonathan Biggar wrote: >1. The following IDL cannot be translated into C++ code by an IDL >compiler for a C++ environment that does not support namespaces: "Cannot" is a little strong -- I believe you can flatten a few key names such as the name of the struct S ala the C mapping, then use typedefs to restore the scoping of the flattened names. The flattened names can be used to break the cycle. Back before 1993 when cfront-based C++ compilers did not handle nested types as template parameters, I wrote an OMG IDL compiler to flatten generated names so they could be used as template parameters, using typedefs to restore their nesting as suggested above. This approach was also needed as late as last year with Microsoft VC++ 4.2 due to nesting-related bugs in that compiler. Flattening may not be the prettiest approach, but it gets the job done and allows code to remain portable. --steve >// IDL >module M { > struct S { > boolean b; > }; > > interface I { > void op(in S arg); > }; > > value V supports A { > }; >}; > >The reason for this is that module M maps to a C++ class when namespaces >are not available, and you end up with the following definition loop: > > POA_M::I must be defined before M::V, since M::V inherits from it > M must be defined before POA_M, because POA_M::I depends on M::S > but defining M also defines M::V > >-- >Jon Biggar >Floorboard Software >jon@floorboard.com >jon@biggar.org > Return-Path: Sender: jon@floorboard.com Date: Mon, 15 Jun 1998 20:54:54 -0700 From: Jonathan Biggar To: Steve Vinoski CC: obval@omg.org, obv-rtf@omg.org, issues@omg.org Subject: Re: Problem with C++ language mapping for Objects-by-value References: <199806160332.XAA19409@boston.iona.ie> Steve Vinoski wrote: > > At 05:54 PM 6/15/98 -0700, Jonathan Biggar wrote: > >1. The following IDL cannot be translated into C++ code by an IDL > >compiler for a C++ environment that does not support namespaces: > > "Cannot" is a little strong -- I believe you can flatten a few key > names > such as the name of the struct S ala the C mapping, then use > typedefs to > restore the scoping of the flattened names. The flattened names can > be used > to break the cycle. > > Back before 1993 when cfront-based C++ compilers did not handle > nested > types as template parameters, I wrote an OMG IDL compiler to flatten > generated names so they could be used as template parameters, using > typedefs to restore their nesting as suggested above. This approach > was > also needed as late as last year with Microsoft VC++ 4.2 due to > nesting-related bugs in that compiler. Flattening may not be the > prettiest > approach, but it gets the job done and allows code to remain > portable. I still maintain that it is impossible, because you can't do this technique for enum types. Try this instead: // IDL module M { enum E { one, two, three }; interface I { void op(in E arg); }; value V supports A { }; }; You can flatten M::E into _M_E (or such), and then flatten the enumerations to avoid collision with other enum types (_M_E_one, _M_E_two, _M_E_three), but you can't then properly declare M::one, M::two, and M::three, because any compiler that doesn't support namespaces almost certainly does not support constant declarations with initializers inside a class declaration. So this won't work as the output: class M { ... const _M_E one = _M_E_one; ... }; Any ideas on this one? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Tue, 16 Jun 1998 10:03:05 -0400 To: Jonathan Biggar From: Steve Vinoski Subject: Re: Problem with C++ language mapping for Objects-by-value Cc: obval@omg.org, obv-rtf@omg.org, issues@omg.org References: <199806160332.XAA19409@boston.iona.ie> At 08:54 PM 6/15/98 -0700, Jonathan Biggar wrote: >I still maintain that it is impossible, because you can't do this >technique for enum types. > >Try this instead: > >// IDL >module M { > enum E { > one, two, three > }; > > interface I { > void op(in E arg); > }; > > value V supports A { > }; >}; > >You can flatten M::E into _M_E (or such), and then flatten the >enumerations to avoid collision with other enum types (_M_E_one, >_M_E_two, _M_E_three), but you can't then properly declare M::one, >M::two, and M::three, because any compiler that doesn't support >namespaces almost certainly does not support constant declarations with >initializers inside a class declaration. So this won't work as the >output: > >class M { > ... > const _M_E one = _M_E_one; > ... >}; > >Any ideas on this one? struct _M_Base { enum E { one, two, three }; }; class M : _M_Base { // The enum is now visible as M::E due to inheritance. // Cycles can be broken using _M_Base::E. }; --steve Return-Path: Sender: jon@floorboard.com Date: Tue, 16 Jun 1998 08:51:43 -0700 From: Jonathan Biggar To: Steve Vinoski CC: obval@omg.org, obv-rtf@omg.org, issues@omg.org Subject: Re: Problem with C++ language mapping for Objects-by-value References: <199806160332.XAA19409@boston.iona.ie> <199806161403.KAA29398@boston.iona.ie> Steve Vinoski wrote: > struct _M_Base { > enum E { one, two, three }; > }; > > class M : _M_Base { > // The enum is now visible as M::E due to inheritance. > // Cycles can be broken using _M_Base::E. > }; Ok Steve, you win. :-) With this approach, I'll admit it is possible, but I'll still maintain that it is messy and difficult to get right. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org