Issue 4344: Typedefs for struct members? (cxx_revision) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: I recently got a query from a customer. Basically, they have a CORBA system that interfaces to some legacy library. Lots of structures are being passed back and forth, many of which contain strings; these need to be passed as char * or as std::string, depending on where they go. So, the customer defined conversion functions that correctly copied a std::string or char * into and out of a string member (using string_dup() or whatever, as appropriate). The problem is that they have to use an undefined type name as the type of the parameter. For example: void copy(const std::string & from, CORBA::string_mgr & to); Of course, "string_mgr" is a mapping-internal type name and therefore the code is non-portable. I don't see an easy work-around that would be within the current mapping. I could use a function that accepts a reference to a struct instead of the string inside the struct, but that then means that I need a different function for each structure type. Or I can write macros that are specific to each ORB to handle it (but that is truly ugly and breaks if the vendor decides to tinker with the internals of their mapping). One way around it all would be to require a typedef to be generated for string members. For example: // IDL struct Foo { string s; }; // C++ namespace CORBA { // ... class string_mgr { /* ... */ }; // Mapping-internal class typedef string_mgr string_member; // New standard name }; struct Foo { CORBA::string_mgr s; // Mapping-internal type name }; This would allow me to portably pass a string member to a function because the mapping would guarantee the existence of a type named "string_member" (or whatever name we can settle on). void copy(const std::string & from, CORBA::string_member & to); (Depending on the mapping implementation, there may be similar issues for other types, such as references or arrays. If there are such mappings, we'd need typedefs for those too.) Basically, wherever a type name that is internal to the mapping can appear, we end up with this kind of problem -- I can't pass a value of that type because I don't know the type name. I'd like to fix that, if possible. Resolution: rejected Revised Text: Actions taken: June 15, 2001: received issue May 13, 2002: closed issue Discussion: Rationale for Rejection Making these operations pure virtual would make things harder for imple-mentations that share the code for both user and system exceptions. End of Annotations:===== Date: Fri, 15 Jun 2001 16:53:27 +1000 (EST) From: Michi Henning Reply-To: C++ Revision Task Force To: C++ Revision Task Force cc: issues@omg.org Subject: Typedefs for struct members? Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ?/p!!a8Ne9H,@e9Gdm!! Hi, I recently got a query from a customer. Basically, they have a CORBA system that interfaces to some legacy library. Lots of structures are being passed back and forth, many of which contain strings; these need to be passed as char * or as std::string, depending on where they go. So, the customer defined conversion functions that correctly copied a std::string or char * into and out of a string member (using string_dup() or whatever, as appropriate). The problem is that they have to use an undefined type name as the type of the parameter. For example: void copy(const std::string & from, CORBA::string_mgr & to); Of course, "string_mgr" is a mapping-internal type name and therefore the code is non-portable. I don't see an easy work-around that would be within the current mapping. I could use a function that accepts a reference to a struct instead of the string inside the struct, but that then means that I need a different function for each structure type. Or I can write macros that are specific to each ORB to handle it (but that is truly ugly and breaks if the vendor decides to tinker with the internals of their mapping). One way around it all would be to require a typedef to be generated for string members. For example: // IDL struct Foo { string s; }; // C++ namespace CORBA { // ... class string_mgr { /* ... */ }; // Mapping-internal class typedef string_mgr string_member; // New standard name }; struct Foo { CORBA::string_mgr s; // Mapping-internal type name }; This would allow me to portably pass a string member to a function because the mapping would guarantee the existence of a type named "string_member" (or whatever name we can settle on). void copy(const std::string & from, CORBA::string_member & to); (Depending on the mapping implementation, there may be similar issues for other types, such as references or arrays. If there are such mappings, we'd need typedefs for those too.) Basically, wherever a type name that is internal to the mapping can appear, we end up with this kind of problem -- I can't pass a value of that type because I don't know the type name. I'd like to fix that, if possible. Opinions? Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi X-Sender: beckwb@postel X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 15 Jun 2001 09:38:50 -0400 To: C++ Revision Task Force From: Bill Beckwith Subject: Re: Typedefs for struct members? Cc: C++ Revision Task Force , issues@omg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: #$Z!!ZG$!!9$@e9MCKe9 Why not just require that all conformant products have the appropriate operators to implicitly convert an implementation-specific manager types to their corresponding ..._var type? Then your customer can use already standardized CORBA::String_var. Bill At 02:53 AM 6/15/01, Michi Henning wrote: >Hi, > >I recently got a query from a customer. Basically, they have a CORBA system >that interfaces to some legacy library. Lots of structures are being passed >back and forth, many of which contain strings; these need to be passed >as char * or as std::string, depending on where they go. > >So, the customer defined conversion functions that correctly copied a >std::string or char * into and out of a string member (using string_dup() >or whatever, as appropriate). The problem is that they have to use >an undefined type name as the type of the parameter. For example: > > void copy(const std::string & from, CORBA::string_mgr & to); > >Of course, "string_mgr" is a mapping-internal type name and therefore the >code is non-portable. > >I don't see an easy work-around that would be within the current mapping. >I could use a function that accepts a reference to a struct instead of >the string inside the struct, but that then means that I need a different >function for each structure type. Or I can write macros that are specific >to each ORB to handle it (but that is truly ugly and breaks if the vendor >decides to tinker with the internals of their mapping). > >One way around it all would be to require a typedef to be generated for >string members. For example: > > // IDL > struct Foo { > string s; > }; > > // C++ > > namespace CORBA { > // ... > class string_mgr { /* ... */ }; // Mapping-internal class > > typedef string_mgr string_member; // New standard name > }; > > struct Foo { > CORBA::string_mgr s; // Mapping-internal type name > }; > >This would allow me to portably pass a string member to a function because >the mapping would guarantee the existence of a type named "string_member" >(or whatever name we can settle on). > > void copy(const std::string & from, CORBA::string_member & to); > >(Depending on the mapping implementation, there may be similar issues for >other types, such as references or arrays. If there are such mappings, >we'd need typedefs for those too.) > >Basically, wherever a type name that is internal to the mapping can appear, >we end up with this kind of problem -- I can't pass a value of that type >because I don't know the type name. I'd like to fix that, if possible. > >Opinions? > > Cheers, > > Michi. >-- >Michi Henning +61 7 3324 9633 >Chief CORBA Scientist +61 4 1118 2700 (mobile) >IONA Technologies +61 7 3324 9799 (fax) >Total Business Integration http://www.ooc.com.au/staff/michi X-Sender: vinoski@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Jun 2001 10:01:40 -0400 To: C++ Revision Task Force From: Steve Vinoski Subject: Re: Typedefs for struct members? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: ;>T!!6:o!! Date: Fri, 15 Jun 2001 12:26:48 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bill Beckwith CC: C++ Revision Task Force , issues@omg.org Subject: Re: Typedefs for struct members? References: <5.0.0.25.2.20010615093640.02a914e0@postel> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: j*c!!QjYd9R9]!!BA3!! Bill Beckwith wrote: > > Why not just require that all conformant products have > the appropriate operators to implicitly convert an > implementation-specific manager types to their corresponding > ..._var type? Then your customer can use already standardized > CORBA::String_var. Won't this cause memory management troubles, or excessive copying? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Sat, 16 Jun 2001 06:56:25 +1000 (EST) From: Michi Henning To: Bill Beckwith cc: C++ Revision Task Force Subject: Re: Typedefs for struct members? In-Reply-To: <5.0.0.25.2.20010615093640.02a914e0@postel> Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: [~W!!/Te!!M(E!!I"T!! On Fri, 15 Jun 2001, Bill Beckwith wrote: > Why not just require that all conformant products have > the appropriate operators to implicitly convert an > implementation-specific manager types to their corresponding > ..._var type? Then your customer can use already standardized > CORBA::String_var. The problem with that is that it would cause extra copying, because _vars make deep copies. I'm looking for something that avoids the copies. What you suggest works if we were to introduce a "no_copy" version of the _var types. (But I'm afraid that this could be very confusing.) Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi Date: Sat, 16 Jun 2001 06:58:15 +1000 (EST) From: Michi Henning To: Steve Vinoski cc: C++ Revision Task Force Subject: Re: Typedefs for struct members? In-Reply-To: <4.3.2.7.2.20010615100000.03fe28a0@mail.boston.amer.iona.com> Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ~8V!!llKe9J>T!!3\He9 On Fri, 15 Jun 2001, Steve Vinoski wrote: > Why can't this be handled using either a template, where the type of the > struct member is treated as a template parameter, or using an > application-specific typedef that's changed when porting to a different ORB? I thought about the template. But, because string members of different structs have different names, I think I'd need as many templates as there are structs, or engage in some preprocessor abuse. The typedef would work, but that then requires everyone to rewrite the typedefs for each ORB they port to. It would be nice to have something that's portable out of the box. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi Date: Fri, 15 Jun 2001 14:17:32 -0700 (Pacific Daylight Time) From: Joachim Achtzehnter To: C++ Revision Task Force Subject: Re: Typedefs for struct members? In-Reply-To: Message-ID: Sender: joachima@van4.realtimeint.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ^K4!!0bh!!D[ Steve Vinoski wrote: > > > > Why can't this be handled using either a template, where the type > > of the struct member is treated as a template parameter, > > I thought about the template. But, because string members of different structs > have different names, I think I'd need as many templates as there are structs, > or engage in some preprocessor abuse. The "names" of the struct members don't matter. As long as they all have the same type it should work. Presumably, there isn't a separate string_mgr type for every occurance? Instead of > void copy(const std::string & from, CORBA::string_mgr & to); how about something like this: template void convert(const std::string& from, StrMgr& to); The compiler should be able to deduce the argument types. Caveat: I haven't actually tried this... Joachim -- work: joachima@netacquire.com (http://www.netacquire.com) private: joachim@kraut.ca (http://www.kraut.ca) Date: Mon, 18 Jun 2001 12:32:25 +1000 (EST) From: Michi Henning To: Joachim Achtzehnter cc: C++ Revision Task Force Subject: Re: Typedefs for struct members? In-Reply-To: Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 6lR!!_>)!!j^Ne9I~Rd9 On Fri, 15 Jun 2001, Joachim Achtzehnter wrote: > The "names" of the struct members don't matter. As long as they all have > the same type it should work. Presumably, there isn't a separate > string_mgr type for every occurance? > > Instead of > > > void copy(const std::string & from, CORBA::string_mgr & to); > > how about something like this: > > template void convert(const std::string& from, StrMgr& to); > > The compiler should be able to deduce the argument types. Caveat: I > haven't actually tried this... Doh! Steve++ pointed out the same thing. I'll go and resign from all my OMG duties now and become a cab driver. Case closed ;-) Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi : Date: Mon, 18 Jun 2001 12:35:10 +1000 (EST) From: Michi Henning Reply-To: C++ Revision Task Force To: C++ Revision Task Force Subject: Proposal for 4344 Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: !M+!!h+Fe9m+O!!"A!e9 Proposal for 4344: Issue due to lack of neuronal activity on part of the submitter. Close no change. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi