Issue 2253: portable includes (cxx_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: We all know that the names of the C++ #include files generated from IDL are not standardized, and are thus the one remaining major source portability issue. One way to fix this would be to agree on some standard filenames, but we"ve tried this before and have never succeeded. Just thinking out loud here, but another way to fix it would be to agree on some standard macro names that applications could use to portably include the appropriate files. For example, define one macro for a client-side include and one macro for a server-side include, both taking the basename of the IDL file as an argument: #ifndef CORBA_CXX_CLIENT_INCLUDE #define CORBA_CXX_CLIENT_INCLUDE(base) <base ## Client.hh> #endif #ifndef CORBA_CXX_SERVER_INCLUDE #define CORBA_CXX_SERVER_INCLUDE(base) <base ## Server.hh> #endif Obviously, the exact definition of the macro would depend on the names of the generated files. I believe these could then be used portably in the client and server source code like this: #include CORBA_CXX_CLIENT_INCLUDE(file) With this approach, nobody has to change the names of the files they currently generate. Resolution: Revised Text: Actions taken: December 14, 1998: received issue Discussion: deferred in June 2011 to the next RTF End of Annotations:===== Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Sun, 13 Dec 1998 01:03:31 -0500 To: cxx_revision@omg.org From: Steve Vinoski Subject: portable includes We all know that the names of the C++ #include files generated from IDL are not standardized, and are thus the one remaining major source portability issue. One way to fix this would be to agree on some standard filenames, but we've tried this before and have never succeeded. Just thinking out loud here, but another way to fix it would be to agree on some standard macro names that applications could use to portably include the appropriate files. For example, define one macro for a client-side include and one macro for a server-side include, both taking the basename of the IDL file as an argument: #ifndef CORBA_CXX_CLIENT_INCLUDE #define CORBA_CXX_CLIENT_INCLUDE(base) #endif #ifndef CORBA_CXX_SERVER_INCLUDE #define CORBA_CXX_SERVER_INCLUDE(base) #endif Obviously, the exact definition of the macro would depend on the names of the generated files. I believe these could then be used portably in the client and server source code like this: #include CORBA_CXX_CLIENT_INCLUDE(file) With this approach, nobody has to change the names of the files they currently generate. I don't care about the names of the macros. I'm just floating the idea to see what folks think of it. --steve Return-Path: Date: Sun, 13 Dec 1998 20:14:31 +1000 (EST) From: Michi Henning To: Steve Vinoski cc: cxx_revision@omg.org Subject: Re: portable includes Organization: Triodia Technologies On Sun, 13 Dec 1998, Steve Vinoski wrote: > #ifndef CORBA_CXX_CLIENT_INCLUDE > #define CORBA_CXX_CLIENT_INCLUDE(base) > #endif > > #ifndef CORBA_CXX_SERVER_INCLUDE > #define CORBA_CXX_SERVER_INCLUDE(base) > #endif > > I don't care about the names of the macros. I'm just floating the > idea to > see what folks think of it. Yes, please!!! 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 Return-Path: Sender: ml@ooc.ooc.com Date: Sun, 13 Dec 1998 09:11:20 -0500 From: Marc Laukien Organization: Object-Oriented Concepts, Inc. To: Steve Vinoski CC: cxx_revision@omg.org Subject: Re: portable includes References: <199812130610.BAA19872@boston.iona.ie> Steve Vinoski wrote: > > We all know that the names of the C++ #include files generated from > IDL are > not standardized, and are thus the one remaining major source > portability > issue. One way to fix this would be to agree on some standard > filenames, > but we've tried this before and have never succeeded. > > Just thinking out loud here, but another way to fix it would be to > agree on > some standard macro names that applications could use to portably > include > the appropriate files. For example, define one macro for a > client-side > include and one macro for a server-side include, both taking the > basename > of the IDL file as an argument: > > #ifndef CORBA_CXX_CLIENT_INCLUDE > #define CORBA_CXX_CLIENT_INCLUDE(base) > #endif > > #ifndef CORBA_CXX_SERVER_INCLUDE > #define CORBA_CXX_SERVER_INCLUDE(base) > #endif > > Obviously, the exact definition of the macro would depend on the > names of > the generated files. > > I believe these could then be used portably in the client and server > source > code like this: > > #include CORBA_CXX_CLIENT_INCLUDE(file) > > With this approach, nobody has to change the names of the files they > currently generate. > > I don't care about the names of the macros. I'm just floating the > idea to > see what folks think of it. Sounds like a good idea. And it's easy for ORB vendors to implement that. Cheers, Marc -- Marc Laukien Phone: (978) 439 9285 x 245 Object-Oriented Concepts, Inc. FAX: (978) 439 9286 44 Manning Rd. WWW: http://www.ooc.com Billerica, MA 01821 E-Mail: mailto:ml@ooc.com Return-Path: Date: Mon, 14 Dec 1998 07:33:27 +1000 (EST) From: Michi Henning To: Steve Vinoski cc: cxx_revision@omg.org Subject: Re: portable includes Organization: Triodia Technologies On Sun, 13 Dec 1998, Michi Henning wrote: > On Sun, 13 Dec 1998, Steve Vinoski wrote: > > > #ifndef CORBA_CXX_CLIENT_INCLUDE > > #define CORBA_CXX_CLIENT_INCLUDE(base) > > #endif > > > > #ifndef CORBA_CXX_SERVER_INCLUDE > > #define CORBA_CXX_SERVER_INCLUDE(base) > > #endif > > > > I don't care about the names of the macros. I'm just floating the > idea to > > see what folks think of it. > > Yes, please!!! Despite my initial enthusiasm ;-) I can see a small snag: Where does the macro definition come from? We'd have to agree on at least one fixed header file name to get that. 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 Return-Path: Sender: jon@floorboard.com Date: Sun, 13 Dec 1998 14:32:15 -0800 From: Jonathan Biggar X-Accept-Language: en To: Michi Henning CC: Steve Vinoski , cxx_revision@omg.org Subject: Re: portable includes References: Michi Henning wrote: > > On Sun, 13 Dec 1998, Michi Henning wrote: > > > On Sun, 13 Dec 1998, Steve Vinoski wrote: > > > > > #ifndef CORBA_CXX_CLIENT_INCLUDE > > > #define CORBA_CXX_CLIENT_INCLUDE(base) > > > #endif > > > > > > #ifndef CORBA_CXX_SERVER_INCLUDE > > > #define CORBA_CXX_SERVER_INCLUDE(base) > > > #endif > > > > > > I don't care about the names of the macros. I'm just floating > the idea to > > > see what folks think of it. > > > > Yes, please!!! > > Despite my initial enthusiasm ;-) I can see a small snag: Where does > the > macro definition come from? We'd have to agree on at least one fixed > header > file name to get that. Right. Is it "corba.h", "Corba.h", "corba.hh", "Corba.hh", or what. :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 14 Dec 1998 08:58:05 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Steve Vinoski , cxx_revision@omg.org Subject: Re: portable includes Organization: Triodia Technologies On Sun, 13 Dec 1998, Jonathan Biggar wrote: > > Despite my initial enthusiasm ;-) I can see a small snag: Where does the > > macro definition come from? We'd have to agree on at least one fixed header > > file name to get that. > > Right. Is it "corba.h", "Corba.h", "corba.hh", "Corba.hh", or what. :-) How about we follow the ISO C++ standard and call it ? That way, no-one can complain that the file extension is wrong :-) 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 Return-Path: Date: Mon, 14 Dec 1998 09:14:26 -0500 From: Paul H Kyzivat Organization: NobleNet To: Steve Vinoski CC: cxx_revision@omg.org Subject: Re: portable includes References: <199812130610.BAA19872@boston.iona.ie> I am all for the goal of making code portable w/r/t includes. But I am not sure this suggestion does the job. I am also just thinking while typing, but I think there are potential problems with the approach: It always generates the include name in a single form - either using the <...> form or the "..." form. But I think the correct form to use may be contextual - it depends on where the IDL, or the generated output of the IDL compiler, is placed relative to the source code that is to use it. - If I am making a self contained project, I may want to have the IDL, the generated output of the IDL, and the code that references the generated output all in the same directory, and reference it via simple relative file names and "..." style includes. This eliminates the need to set up include paths. - If I have a family of related programs that reference the same IDL, I might want to have a directory tree with the IDL and its generated outputs at the top and a subdirectory for each referencing project. Then each project can reference the generated code with "../xxx". - If I have some more complex sharing plan then I might want to set up include paths and use <...> syntax for my includes. My basic point is that the way in which file entry names are related to the name of an IDL file is orthogonal to where those files are located in the file system. The name relationships are probably well defined for a particular orb, but responsibility for deciding where those files reside in the file system and how they are located is distributed between the orb and the user. I think that before we can make much progress here we will need to seek some more basic common ground. (This may or may not be possible.) Paul Steve Vinoski wrote: > > We all know that the names of the C++ #include files generated from > IDL are > not standardized, and are thus the one remaining major source > portability > issue. One way to fix this would be to agree on some standard > filenames, > but we've tried this before and have never succeeded. > > Just thinking out loud here, but another way to fix it would be to > agree on > some standard macro names that applications could use to portably > include > the appropriate files. For example, define one macro for a > client-side > include and one macro for a server-side include, both taking the > basename > of the IDL file as an argument: > > #ifndef CORBA_CXX_CLIENT_INCLUDE > #define CORBA_CXX_CLIENT_INCLUDE(base) > #endif > > #ifndef CORBA_CXX_SERVER_INCLUDE > #define CORBA_CXX_SERVER_INCLUDE(base) > #endif > > Obviously, the exact definition of the macro would depend on the > names > of > the generated files. > > I believe these could then be used portably in the client and server > source > code like this: > > #include CORBA_CXX_CLIENT_INCLUDE(file) > > With this approach, nobody has to change the names of the files they > currently generate. > > I don't care about the names of the macros. I'm just floating the > idea > to > see what folks think of it. > > --steve Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Mon, 14 Dec 1998 11:49:55 -0500 To: Paul H Kyzivat From: Steve Vinoski Subject: Re: portable includes Cc: cxx_revision@omg.org References: <199812130610.BAA19872@boston.iona.ie> Paul, Just because something doesn't solve 110% of the problem is no reason to throw it out completely. I think the suggested approach solves the problem for the majority of cases and would be fairly painless for all to support and use. We could easily add macro variations for "" vs. <>, but more complex include paths like the ones you've mentioned can be (and should be) handled by application-specific portability layers. --steve At 09:14 AM 12/14/98 -0500, Paul H Kyzivat wrote: >I am all for the goal of making code portable w/r/t includes. >But I am not sure this suggestion does the job. I am also just thinking >while typing, but I think there are potential problems with the >approach: > >It always generates the include name in a single form - either using the ><...> form or the "..." form. But I think the correct form to use may be >contextual - it depends on where the IDL, or the generated output of the >IDL compiler, is placed relative to the source code that is to use it. > >- If I am making a self contained project, I may want to have the IDL, >the generated output of the IDL, and the code that references the >generated output all in the same directory, and reference it via simple >relative file names and "..." style includes. This eliminates the need >to set up include paths. > >- If I have a family of related programs that reference the same IDL, I >might want to have a directory tree with the IDL and its generated >outputs at the top and a subdirectory for each referencing project. Then >each project can reference the generated code with "../xxx". > >- If I have some more complex sharing plan then I might want to set up >include paths and use <...> syntax for my includes. > >My basic point is that the way in which file entry names are related to >the name of an IDL file is orthogonal to where those files are located >in the file system. The name relationships are probably well defined for >a particular orb, but responsibility for deciding where those files >reside in the file system and how they are located is distributed >between the orb and the user. > >I think that before we can make much progress here we will need to seek >some more basic common ground. (This may or may not be possible.) > > Paul > >Steve Vinoski wrote: >> >> We all know that the names of the C++ #include files generated from >> IDL are >> not standardized, and are thus the one remaining major source >> portability >> issue. One way to fix this would be to agree on some standard >> filenames, >> but we've tried this before and have never succeeded. >> >> Just thinking out loud here, but another way to fix it would be to >> agree on >> some standard macro names that applications could use to portably >> include >> the appropriate files. For example, define one macro for a client-side >> include and one macro for a server-side include, both taking the >> basename >> of the IDL file as an argument: >> >> #ifndef CORBA_CXX_CLIENT_INCLUDE >> #define CORBA_CXX_CLIENT_INCLUDE(base) >> #endif >> >> #ifndef CORBA_CXX_SERVER_INCLUDE >> #define CORBA_CXX_SERVER_INCLUDE(base) >> #endif >> >> Obviously, the exact definition of the macro would depend on the names >> of >> the generated files. >> >> I believe these could then be used portably in the client and server >> source >> code like this: >> >> #include CORBA_CXX_CLIENT_INCLUDE(file) >> >> With this approach, nobody has to change the names of the files they >> currently generate. >> >> I don't care about the names of the macros. I'm just floating the idea >> to >> see what folks think of it. >> >> --steve > Return-Path: Date: Mon, 14 Dec 1998 13:29:33 -0500 From: Paul H Kyzivat Organization: NobleNet To: Steve Vinoski CC: cxx_revision@omg.org Subject: Re: portable includes References: <199812130610.BAA19872@boston.iona.ie> <199812141650.LAA15823@boston.iona.ie> Steve Vinoski wrote: > > Paul, > > Just because something doesn't solve 110% of the problem is no > reason > to > throw it out completely. I think the suggested approach solves the > problem > for the majority of cases and would be fairly painless for all to > support > and use. We could easily add macro variations for "" vs. <>, but > more > complex include paths like the ones you've mentioned can be (and > should be) > handled by application-specific portability layers. > > --steve I gather we are all thinking while speaking without having spent a great deal of time looking for the best solution. I agree with you that it may not be necessary to cover all cases. But neither should we be excluding cases without first figuring out what they might be. Perhaps there is a solution that covers more cases, or that covers a more significant set of cases. What do you expect the value of the macro argument to be? Is it the entry name of the idl file, with the ".idl" removed? Can it be prefixed with some sort of relative or absolute directory path? What usage scenario(s) do you intend this to cover? Some other not-so-unusual cases to consider: - Does it hurt to include both the client and server files? Is that what I should do if I want to be both client and server? Return-Path: Date: Tue, 15 Dec 1998 09:31:29 +1000 (EST) From: Michi Henning To: Paul H Kyzivat cc: Steve Vinoski , cxx_revision@omg.org Subject: Re: portable includes Organization: Triodia Technologies Content-ID: On Mon, 14 Dec 1998, Paul H Kyzivat wrote: > It always generates the include name in a single form - either using the > <...> form or the "..." form. But I think the correct form to use may be > contextual - it depends on where the IDL, or the generated output of the > IDL compiler, is placed relative to the source code that is to use it. It doesn't matter whether "" or <> are used I think -- either way, you can direct the proprocessor to look in the right place with a -I directive. > My basic point is that the way in which file entry names are related to > the name of an IDL file is orthogonal to where those files are located > in the file system. The name relationships are probably well defined for > a particular orb, but responsibility for deciding where those files > reside in the file system and how they are located is distributed > between the orb and the user. > > I think that before we can make much progress here we will need to seek > some more basic common ground. (This may or may not be possible.) I don't think this affects Steve's proposal. Right now, you have exactly the same issue already. In particular, the include directives generated inside the generated header files already require you to add a -I directive (at least with those ORBs I've used). 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 Return-Path: Date: Tue, 15 Dec 1998 09:51:10 -0500 From: Paul H Kyzivat Organization: NobleNet To: Michi Henning CC: Steve Vinoski , cxx_revision@omg.org Subject: Re: portable includes References: Michi Henning wrote: > > On Mon, 14 Dec 1998, Paul H Kyzivat wrote: > > > It always generates the include name in a single form - either > using > the > > <...> form or the "..." form. But I think the correct form to use > may be > > contextual - it depends on where the IDL, or the generated output > of > the > > IDL compiler, is placed relative to the source code that is to use > it. > > It doesn't matter whether "" or <> are used I think -- either way, > you > can direct the proprocessor to look in the right place with a -I > directive. When <> is used files often will not be found in the referencing directory unless "." is specified via -I. > > > My basic point is that the way in which file entry names are > related > to > > the name of an IDL file is orthogonal to where those files are > located > > in the file system. The name relationships are probably well > defined > for > > a particular orb, but responsibility for deciding where those > files > > reside in the file system and how they are located is distributed > > between the orb and the user. > > > > I think that before we can make much progress here we will need to > seek > > some more basic common ground. (This may or may not be possible.) > > I don't think this affects Steve's proposal. Right now, you have > exactly > the same issue already. In particular, the include directives > generated > inside the generated header files already require you to add a -I > directive > (at least with those ORBs I've used). Our orb does not require a project specific -I setting if the compiler outputs are local to the project. (You do need orb-specific -I values, but they are constant across projects.) I am not opposed to doing something here. But I would like to clearly define the problem before standardizing a solution to it. I gather that the goal is to improve the portability of code between orbs. It would be useful to have a list of the top N remaining obstacles to portability. I will venture to guess that there are still gray areas around the POA spec that will be greater obstacles than this. Perhaps it would be helpful to pick some simple programs and do the exercise of porting them between orbs. Subject: FW: remember issue 2253? Date: Fri, 16 Aug 2002 13:03:17 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: remember issue 2253? Thread-Index: AcJExnGQFQ6tMjcPRJa/X9p6gasX5QAgD0lw From: "Vinoski, Stephen" To: X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id g7GGxnX06583 Hi Juergen, sorry to bother you again, but would you mind posting this for me to the cxx-revision list? Somehow my registered address is screwed up, which is in the process of being fixed, but I'm currently unable to post. thanks, --steve -----Original Message----- From: Vinoski, Stephen Sent: Thursday, August 15, 2002 9:44 PM To: 'cxx_revision@omg.org' Subject: remember issue 2253? Remember issue 2253 -- portable includes? My original proposal to resolve it is below (note that if you look at the issues list on the web, the proposal is mangled because of the <> characters in the original text, so it doesn't make sense -- use the corrected version below instead). If you look back through the archives, you'll find there was general consensus on the approach. The only issues raised were from one individual who, IMO, was being overly nit-picky and unnecessarily difficult. Is it still worth trying to work this into the standard, or has everyone concerned with portability already figured out their own ways of taking care of this? --steve We all know that the names of the C++ #include files generated from IDL are not standardized, and are thus the one remaining major source portability issue. One way to fix this would be to agree on some standard filenames, but we"ve tried this before and have never succeeded. Just thinking out loud here, but another way to fix it would be to agree on some standard macro names that applications could use to portably include the appropriate files. For example, define one macro for a client-side include and one macro for a server-side include, both taking the basename of the IDL file as an argument: #ifndef CORBA_CXX_CLIENT_INCLUDE #define CORBA_CXX_CLIENT_INCLUDE(base) < base ## C.hh > #endif #ifndef CORBA_CXX_SERVER_INCLUDE #define CORBA_CXX_SERVER_INCLUDE(base) < base ## S.hh > #endif Obviously, the exact definition of the macro would depend on the names of the generated files. I believe these could then be used portably in the client and server source code like this: #include CORBA_CXX_CLIENT_INCLUDE(file) With this approach, nobody has to change the names of the files they currently generate. X-Sender: beckwb@192.168.10.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 Aug 2002 16:35:57 -0400 To: steve.vinoski@iona.com, cxx_revision@omg.org From: Bill Beckwith Subject: Re: Fwd: FW: remember issue 2253? >>From: Vinoski, Stephen >>Sent: Thursday, August 15, 2002 9:44 PM >>To: 'cxx_revision@omg.org' >>Subject: remember issue 2253? >> >> >>Remember issue 2253 -- portable includes? My original proposal to >>resolve >>it is below (note that if you look at the issues list on the web, >>the >>proposal is mangled because of the <> characters in the original >>text, so >>it doesn't make sense -- use the corrected version below instead). >> >>If you look back through the archives, you'll find there was general >>consensus on the approach. The only issues raised were from one >>individual >>who, IMO, was being overly nit-picky and unnecessarily difficult. Is >>it >>still worth trying to work this into the standard, or has everyone >>concerned with portability already figured out their own ways of >>taking >>care of this? >> >>--steve Yes, this is a major annoyance to CORBA developers. Thanks for addressing it. >> We all know that the names of the C++ #include files generated from IDL are >> not standardized, and are thus the one remaining major source portability >> issue. One way to fix this would be to agree on some standard filenames, >> but we"ve tried this before and have never succeeded. >> >> Just thinking out loud here, but another way to fix it would be to agree on >> some standard macro names that applications could use to portably include >> the appropriate files. For example, define one macro for a client-side >> include and one macro for a server-side include, both taking the basename >> of the IDL file as an argument: >> >> #ifndef CORBA_CXX_CLIENT_INCLUDE >> #define CORBA_CXX_CLIENT_INCLUDE(base) < base ## C.hh > >> #endif >> >> #ifndef CORBA_CXX_SERVER_INCLUDE >> #define CORBA_CXX_SERVER_INCLUDE(base) < base ## S.hh > >> #endif This solves one of the annoyances to application engineers: what file name to #include. But it still doesn't address all of the annoyances related to configuration management systems and makefiles expecting certain file naming schemes. I'm not sure the best way to address all of these problems. Maybe an IDL pragma to specify which client and server file name extensions to use. Bill >> Obviously, the exact definition of the macro would depend on the names of >> the generated files. >> >> I believe these could then be used portably in the client and server source >> code like this: >> >> #include CORBA_CXX_CLIENT_INCLUDE(file) >> >> With this approach, nobody has to change the names of the files they >> currently generate. Date: Fri, 16 Aug 2002 17:25:44 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Bill Beckwith Cc: steve.vinoski@iona.com, cxx_revision@omg.org Subject: Re: Fwd: FW: remember issue 2253? Bill Beckwith wrote: > > >>From: Vinoski, Stephen > >>Sent: Thursday, August 15, 2002 9:44 PM > >>To: 'cxx_revision@omg.org' > >>Subject: remember issue 2253? > >> > >> > >>Remember issue 2253 -- portable includes? My original proposal to resolve > >>it is below (note that if you look at the issues list on the web, the > >>proposal is mangled because of the <> characters in the original text, so > >>it doesn't make sense -- use the corrected version below instead). > >> > >>If you look back through the archives, you'll find there was general > >>consensus on the approach. The only issues raised were from one individual > >>who, IMO, was being overly nit-picky and unnecessarily difficult. Is it > >>still worth trying to work this into the standard, or has everyone > >>concerned with portability already figured out their own ways of taking > >>care of this? > >> > >>--steve > > Yes, this is a major annoyance to CORBA developers. > Thanks for addressing it. > > >> We all know that the names of the C++ #include files generated from IDL are > >> not standardized, and are thus the one remaining major source portability > >> issue. One way to fix this would be to agree on some standard filenames, > >> but we"ve tried this before and have never succeeded. > >> > >> Just thinking out loud here, but another way to fix it would be to agree on > >> some standard macro names that applications could use to portably include > >> the appropriate files. For example, define one macro for a client-side > >> include and one macro for a server-side include, both taking the basename > >> of the IDL file as an argument: > >> > >> #ifndef CORBA_CXX_CLIENT_INCLUDE > >> #define CORBA_CXX_CLIENT_INCLUDE(base) < base ## C.hh > > >> #endif > >> > >> #ifndef CORBA_CXX_SERVER_INCLUDE > >> #define CORBA_CXX_SERVER_INCLUDE(base) < base ## S.hh > > >> #endif > > This solves one of the annoyances to application engineers: > what file name to #include. But it still doesn't address all > of the annoyances related to configuration management systems > and makefiles expecting certain file naming schemes. > > I'm not sure the best way to address all of these problems. > Maybe an IDL pragma to specify which client and server file name > extensions to use. Oh please!!!!! Anything but another IDL pragma.:-) You really do not want to depend on someone setting those pragmas right when there is a simple way of canonically generating the right names from the name of the IDL file. I like Steve's idea. Make it part of the C++ mapping standard. We had used almost exactly the same names as proposed by Steve in the Chorus/Esprit COOL project. This is an implementation langauge specific issue anyway. Reply-To: "Michi Henning" From: "Michi Henning" To: "Jishnu Mukerji" , "Bill Beckwith" Cc: , Subject: Re: Fwd: FW: remember issue 2253? Date: Sat, 17 Aug 2002 07:53:24 +1000 Organization: Triodia Technologies X-Mailer: Microsoft Outlook Express 6.00.2600.0000 I'd be strongly in favour of getting such macros defined. After all these years, it's about time :-) My only nitpick: make the macro name a bit shorter. Maybe CORBA_CLIENT_HDR and CORBA_SERVER_HDR? There is no need for a _CXX_ in the macro name. After all, by the time I write the source, I should already know what language I'm using ;-) This would then give us #include CORBA_CLIENT_HDR(base) and #include CORBA__SERVER_HDR(base) which looks acceptable to me. While we are at it: there is another thing that should be standardized at the same time: - We need to state which include file contains the above macro definitions. I would suggest corba_cxx (notice: no .h extension). Without this, we are still in vendor-dependent country... - A source file that only contains only a single one of the above macros (preceded by #include , of course) must compile without error. This makes sure that I need to *only* include corba_cxx before I can go on my merry way and that the generated headers don't depend on anything else. It would also make sure that, if the server header requires the client header, it is the server header that is responsible for including the client header (or any other include files it depends on), not the developer. Cheers, Michi. -- Michi Henning Ph: +61 4 1118-2700 Triodia Technologies http://www.triodia.com/staff/michi Sender: jbiggar@Resonate.com Date: Fri, 16 Aug 2002 15:01:18 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: Bill Beckwith , steve.vinoski@iona.com, cxx_revision@omg.org Subject: Re: Fwd: FW: remember issue 2253? Jishnu Mukerji wrote: > > Yes, this is a major annoyance to CORBA developers. > > Thanks for addressing it. > > > > >> We all know that the names of the C++ #include files generated from IDL are > > >> not standardized, and are thus the one remaining major source portability > > >> issue. One way to fix this would be to agree on some standard filenames, > > >> but we"ve tried this before and have never succeeded. > > >> > > >> Just thinking out loud here, but another way to fix it would be to agree on > > >> some standard macro names that applications could use to portably include > > >> the appropriate files. For example, define one macro for a client-side > > >> include and one macro for a server-side include, both taking the basename > > >> of the IDL file as an argument: > > >> > > >> #ifndef CORBA_CXX_CLIENT_INCLUDE > > >> #define CORBA_CXX_CLIENT_INCLUDE(base) < base ## C.hh > > > >> #endif > > >> > > >> #ifndef CORBA_CXX_SERVER_INCLUDE > > >> #define CORBA_CXX_SERVER_INCLUDE(base) < base ## S.hh > > > >> #endif > > > > This solves one of the annoyances to application engineers: > > what file name to #include. But it still doesn't address all > > of the annoyances related to configuration management systems > > and makefiles expecting certain file naming schemes. > > > > I'm not sure the best way to address all of these problems. > > Maybe an IDL pragma to specify which client and server file name > > extensions to use. > > Oh please!!!!! Anything but another IDL pragma.:-) You really do not > want to depend on someone setting those pragmas right when there is a > simple way of canonically generating the right names from the name of > the IDL file. Pragmas suck. :) > I like Steve's idea. Make it part of the C++ mapping standard. We had > used almost exactly the same names as proposed by Steve in the > Chorus/Esprit COOL project. This is an implementation langauge specific > issue anyway. However, there is a little more to consider than just this. For example, I know of at least one C++ ORB implementation that has a third include file, for the OBV_ valuetype classes, for the reason that only source files that actually provide a valuetype implementation should suffer the overhead of seeing the OBV_ class definitions. So now, is it just 2 include files, or is it 3? Another issue: some ORB implementations include the contents of the client include file in the server include file. Others do not. So is it just 1 include file, 2 include files, or 3? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 16 Aug 2002 18:09:21 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: Bill Beckwith , steve.vinoski@iona.com, cxx_revision@omg.org Subject: Re: Fwd: FW: remember issue 2253? Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > > This solves one of the annoyances to application engineers: > > > what file name to #include. But it still doesn't address all > > > of the annoyances related to configuration management systems > > > and makefiles expecting certain file naming schemes. > > > > > > I'm not sure the best way to address all of these problems. > > > Maybe an IDL pragma to specify which client and server file name > > > extensions to use. > > > > Oh please!!!!! Anything but another IDL pragma.:-) You really do > > > not > > want to depend on someone setting those pragmas right when there > > > is a > > simple way of canonically generating the right names from the name > > > of > > the IDL file. > > Pragmas suck. :) > > > I like Steve's idea. Make it part of the C++ mapping standard. We > > > had > > used almost exactly the same names as proposed by Steve in the > > Chorus/Esprit COOL project. This is an implementation langauge > > > specific > > issue anyway. > > However, there is a little more to consider than just this. For > example, I know of at least one C++ ORB implementation that has a > > > third > include file, for the OBV_ valuetype classes, for the reason that > > > only > source files that actually provide a valuetype implementation should > suffer the overhead of seeing the OBV_ class definitions. > > So now, is it just 2 include files, or is it 3? > > Another issue: some ORB implementations include the contents of the > client include file in the server include file. Others do not. > > So is it just 1 include file, 2 include files, or 3? Yes, agreed to all that. It is still a C++ language mapping specific issue, and I am sure there could be similar issues for other language mappings. I just wanted to make sure that we did not go about planting various droppings in the IDL for handling this.:-) Now what if the standard says that the name of the client include file in C++ will be "X" and the name of the server include file will be "Y", and leaves it upto specific implementations to figure out how they wish to get the right things into those files? As far as the user of these files is concerned they just include either "X" or "Y" depending on whether they are doing the client end or the server end. Does that not work? Jishnu. X-Sender: beckwb@192.168.10.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 Aug 2002 18:24:26 -0400 To: steve.vinoski@iona.com, cxx_revision@omg.org From: Bill Beckwith Subject: Re: Fwd: FW: remember issue 2253? At 06:09 PM 8/16/2002, Jishnu Mukerji wrote: > >It is still a C++ language mapping specific >issue, and I am sure there could be similar issues for other language >mappings. I just wanted to make sure that we did not go about planting >various droppings in the IDL for handling this.:-) Yes, I see your (and others') points about this. O.K., pragma's suck. >Now what if the standard says that the name of the client include file >in C++ will be "X" and the name of the server include file will be "Y", >and leaves it upto specific implementations to figure out how they wish >to get the right things into those files? As far as the user of these >files is concerned they just include either "X" or "Y" depending on >whether they are doing the client end or the server end. Does that not >work? That is interesting. So if the rule was: filename.idl => filename_CC.hhh filename_SS.hhh [I'm intentionally picking mappings that I wouldn't want and don't think anyone has ever used!] Then an IDL compiler could generate using these names or just generate two files that with these names that just #include the vendor specific header files. Also, I like Michi's suggestion about a standard file with the macro definitions in them. I don't think you have to leave out the ".h" to avoid file name collisions. If there is a collision the vendor can always add the macros to the already existing file. Bill Reply-To: "Michi Henning" From: "Michi Henning" To: , , "Bill Beckwith" Subject: Re: Fwd: FW: remember issue 2253? Date: Sun, 18 Aug 2002 09:32:02 +1000 Organization: Triodia Technologies X-Mailer: Microsoft Outlook Express 6.00.2600.0000 > > Also, I like Michi's suggestion about a standard file > with the macro definitions in them. I don't think > you have to leave out the ".h" to avoid file name > collisions. If there is a collision the vendor can > always add the macros to the already existing file. Agreed, a collision is unlikely. I suggested the version without the ".h" simply because that is how modern C++ header files are done. Cheers, Michi. Subject: RE: FW: remember issue 2253? Date: Sun, 18 Aug 2002 12:48:04 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: FW: remember issue 2253? Thread-Index: AcJFcJRIl9VUsl/NRc+iBf0mdW8BTwBZg75g From: "Vinoski, Stephen" To: "triodia.com, michi" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id g7IGimX28348 Hi Michi, I'm not tied to the macro names in my original email. Feel free to make the macro names anything you like in the course of refining this proposal. The only thing I tried to do with respect to names was to prefix the macros with something like "CORBA_" or "CORBA_CXX_" so as to minimize the chance of name clashes. I think you need to continue to take this into account if you change the names. --steve > -----Original Message----- > From: triodia.com, michi > Sent: Friday, August 16, 2002 5:53 PM > To: Jishnu Mukerji; Bill Beckwith > Cc: Vinoski, Stephen; cxx_revision@omg.org > Subject: Re: FW: remember issue 2253? > > > I'd be strongly in favour of getting such macros defined. > After all these years, it's about time :-) > > My only nitpick: make the macro name a bit shorter. > Maybe CORBA_CLIENT_HDR and CORBA_SERVER_HDR? > There is no need for a _CXX_ in the macro name. After > all, by the time I write the source, I should already know > what language I'm using ;-) > > This would then give us > > #include CORBA_CLIENT_HDR(base) > and > #include CORBA__SERVER_HDR(base) > > which looks acceptable to me. > > While we are at it: there is another thing that should be > standardized at the same time: > > - We need to state which include file contains > the above macro definitions. I would suggest > corba_cxx (notice: no .h extension). Without > this, we are still in vendor-dependent country... > > - A source file that only contains only a single one > of the above macros (preceded by #include > , of course) must compile without > error. > > This makes sure that I need to *only* include corba_cxx > before I can go on my merry way and that the generated > headers don't depend on anything else. It would also > make sure that, if the server header requires the client > header, it is the server header that is responsible for > including the client header (or any other include files > it depends on), not the developer. > > Cheers, > > Michi. > -- > Michi Henning Ph: +61 4 1118-2700 > Triodia Technologies http://www.triodia.com/staff/michi > > > Reply-To: "Michi Henning" From: "Michi Henning" To: "Vinoski, Stephen" Cc: Subject: Re: FW: remember issue 2253? Date: Mon, 19 Aug 2002 07:02:07 +1000 Organization: Triodia Technologies X-Mailer: Microsoft Outlook Express 6.00.2600.0000 > Hi Michi, I'm not tied to the macro names in my original email. Feel free to make the macro names anything you like in the course of refining this proposal. The only thing I tried to do with respect to names was to prefix the macros with something like "CORBA_" or "CORBA_CXX_" so as to minimize the chance of name clashes. I think you need to continue to take this into account if you change the names. Right. I'd just like to see them a bit shorter. The _CXX_ really is redundant, given that the header can possibly be for anything but C++. I think CORBA_CLIENT_HDR and CORBA_SERVER_HDR are safe from clashes, and they are a bit shorter. Cheers, Michi. Date: Mon, 19 Aug 2002 11:40:58 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Bill Beckwith Cc: steve.vinoski@iona.com, cxx_revision@omg.org Subject: Re: Fwd: FW: remember issue 2253? Bill Beckwith wrote: > > At 06:09 PM 8/16/2002, Jishnu Mukerji wrote: > > > >It is still a C++ language mapping specific > >issue, and I am sure there could be similar issues for other language > >mappings. I just wanted to make sure that we did not go about planting > >various droppings in the IDL for handling this.:-) > > Yes, I see your (and others') points about this. O.K., pragma's suck. Thank you.:-) > >Now what if the standard says that the name of the client include file > >in C++ will be "X" and the name of the server include file will be "Y", > >and leaves it upto specific implementations to figure out how they wish > >to get the right things into those files? As far as the user of these > >files is concerned they just include either "X" or "Y" depending on > >whether they are doing the client end or the server end. Does that not > >work? > > That is interesting. So if the rule was: > > filename.idl => filename_CC.hhh filename_SS.hhh > > [I'm intentionally picking mappings that I wouldn't want > and don't think anyone has ever used!] > > Then an IDL compiler could generate using these names > or just generate two files that with these names that > just #include the vendor specific header files. That is the general idea. That way we protect the app producer's source code portability, and yet give freedom to individual vendors to organize their internal structure of IDL files. Jishnu. X-Sender: beckwb@192.168.10.3 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 19 Aug 2002 11:56:34 -0400 To: cxx_revision@omg.org, steve.vinoski@iona.com From: Bill Beckwith Subject: Re: Fwd: FW: remember issue 2253? At 11:40 AM 8/19/2002, Jishnu Mukerji wrote: >Bill Beckwith wrote: >> >> At 06:09 PM 8/16/2002, Jishnu Mukerji wrote: >> > >> >Now what if the standard says that the name of the client include file >> >in C++ will be "X" and the name of the server include file will be "Y", >> >and leaves it upto specific implementations to figure out how they wish >> >to get the right things into those files? As far as the user of these >> >files is concerned they just include either "X" or "Y" depending on >> >whether they are doing the client end or the server end. Does that not >> >work? >> >> That is interesting. So if the rule was: >> >> filename.idl => filename_CC.hhh filename_SS.hhh >> >> [I'm intentionally picking mappings that I wouldn't want >> and don't think anyone has ever used!] >> >> Then an IDL compiler could generate using these names >> or just generate two files that with these names that >> just #include the vendor specific header files. > >That is the general idea. That way we protect the app producer's source >code portability, and yet give freedom to individual vendors to organize >their internal structure of IDL files. O.K. I like it. Good suggestion. Bill