Issue 306: Portability and the #include directive (orb_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: #include has same definition that C and C++ programmers are used to.HP treats #include at global scope as merely introducing declarations. This idea needs closer examination Resolution: close no change in 2.4 Revised Text: Actions taken: November 23, 1996: received issue August 12, 1999: close dissue Discussion: End of Annotations:===== >From mail Sat Nov 23 15:44 EST 1996 Date: Sat, 23 Nov 1996 15:41:19 -0500 (EST) X-Sender: kegeisi@clark.net To: orbos@omg.org, issues@omg.org From: kegeisi@clark.net (Ken Geisinger) Subject: Portability and the #include directive Content-Length: 3358 I have asked about this before but got no real responses on this. So, I'm trying again: I have investigated a couple of ORB products and have found what I consider to be an alarming discrepancy in the way these products treat the #include direction in their IDL compilers. I do not know if any work has been done or any discussions have occurred concerning this problem, but I truly believe that, if this issue is not resolve, we will never attain portability among ORB products. The current release of ICL's DAIS supports the notion that #include has the same definition that C and C++ programmers have grown accustomed. That is "include means to insert the code contained within the identified file and proceed with the compilation as if all of the code is in the same file. This, of course, generates the client and implementation code for the IDL for all interfaces, etc contained in the file(s). DAIS also currently supports an "#import" directive which tells the compiler to be aware of the definitions in the files, but do not generate code for it. "#import" is not part of OMG IDL. Digital's ObjectBroker (version 2.5) also supports the "traditional" notion of #include. It supports compile time flags as to which object implementation code is to be generated during the compile. Client code, however, can only be generated in one shot. This did make compiling a framework's worth of IDL somewhat awkward. I know that Digital has taken some measures to simplify their IDL compiler since version 2.5, but I am not aware of what exactly they did. IONA's Orbix can support the "traditional" notion of #include or treat it as DAIS's #import directive by a compiler switch flag. A possible problem is that it becomes an all or nothing option. I'm not saying it's a bad idea. I just want to lay as many of the cards out as I am aware. Thanks to Steve Vinoski, I have been made aware that HP treats #include at global scope as merely introducing declarations, i.e., no code is generated for such #includes. If on the other hand an #include appears at non-global scope, e.g., inside a module, then it gets textually included and code is generated for it. An interesting idea that may merit closer examiniation. The basic problem is this. If you are developing a framework, there may be instances where interfaces will need to exist that allow the exchanging of CORBA objects from one implementation to another. It would be extremely useful if the interfaces can be designed so that only objects of the specific type can be passed and that this checking can be done at code compile time (in C++, etc...) or in the local process space of the client at run-time as opposed to always in the receiving object implementation at run-time. Some framework ideas that I have incountered have interactions of this nature all over the place so that, for IDL compilers which do not support the "import" type method, one might as well keep everything in one large IDL file. Once some developer starts taking advantage of the "import" methodology, that developer has locked his code to that ORB. Thus, there is no portability. #pragmas can also present similar problems, but at least the OMG has stated that if the pragma is not for a particular compiler, then it is to be ignored. You cannot, however, ignore #include. -----Ken Geisinger >From mail Sat Nov 23 17:34 EST 1996 From: jmischki@wheel.dcn.davis.ca.us (Jeffrey Mischkinsky) Subject: Re: Portability and the #include directive To: kegeisi@clark.net (Ken Geisinger) Date: Sat, 23 Nov 1996 14:30:55 -0800 (PST) Cc: orbos@omg.org, issues@omg.org Content-Length: 5213 > > I have asked about this before but got no real responses on this. So, I'm > trying again: > > I have investigated a couple of ORB products and have found what I > consider to be an alarming discrepancy in the way these products treat the > #include direction in their IDL compilers. I do not know if any work has > been done or any discussions have occurred concerning this problem, but I > truly believe that, if this issue is not resolve, we will never attain > portability among ORB products. I agree that this is issue that needs to be addressed. However, I believe that the current CORBA 2.0 spec is pretty clear on the meaning of the #include directive. It states that "Text in files included with a #include directive is treated as if it appeared in the including file." The "alarming discrepancy" you note is caused by the fact that many vendors have chosen not to implement these semantics. While I agree that there are in fact good reasons for wanting/needing #import-style semantics and even for arguing that the #include semantics as specified in the spec are broken, the current spec is actually quite clear. But until there are compliance tests, things like this will be an issue. Again there are really 2 issues: a) If your favorite ORB vendor doesn't implement the spec and you want portability, then ask them to. and b) If you think the current spec is broken, deficient, etc. file an issue and then agitate to have it addressed. The situation is a bit more complex for the following reason. Actually the spec says OMG IDL preprocessing is based upon C++, and that "A complete description of the preprocessing facilities may be found in The Annoated C++ Reference Manual, Chapter 10.) So according to the spec, a "real", i.e. OMG conformant compiler has to support all the preprocessing stuff that is part of the C++ std., essentially cpp. So an IDL compiler isn't using cpp, or equivalent, it doesn't correctly implement the spec. To the extent that many vendors don't implement the syntax and semantics specified in the spec, users have got a portablity problem. > > The current release of ICL's DAIS supports the notion that #include has > the same definition that C and C++ programmers have grown accustomed. That > is "include means to insert the code contained within the identified file > and proceed with the compilation as if all of the code is in the same file. > This, of course, generates the client and implementation code for the IDL > for all interfaces, etc contained in the file(s). DAIS also currently > supports an "#import" directive which tells the compiler to be aware of the > definitions in the files, but do not generate code for it. "#import" is not > part of OMG IDL. > > Digital's ObjectBroker (version 2.5) also supports the "traditional" > notion of #include. It supports compile time flags as to which object > implementation code is to be generated during the compile. Client code, > however, can only be generated in one shot. This did make compiling a > framework's worth of IDL somewhat awkward. I know that Digital has taken > some measures to simplify their IDL compiler since version 2.5, but I am not > aware of what exactly they did. > > IONA's Orbix can support the "traditional" notion of #include or treat it > as DAIS's #import directive by a compiler switch flag. A possible problem is > that it becomes an all or nothing option. I'm not saying it's a bad idea. I > just want to lay as many of the cards out as I am aware. > > Thanks to Steve Vinoski, I have been made aware that HP treats #include > at global scope as merely introducing declarations, i.e., no code is > generated for such #includes. If on the other hand an #include appears at > non-global scope, e.g., inside a module, then it gets textually included and > code is generated for it. An interesting idea that may merit closer > examiniation. > > The basic problem is this. If you are developing a framework, there may > be instances where interfaces will need to exist that allow the exchanging > of CORBA objects from one implementation to another. It would be extremely > useful if the interfaces can be designed so that only objects of the > specific type can be passed and that this checking can be done at code > compile time (in C++, etc...) or in the local process space of the client at > run-time as opposed to always in the receiving object implementation at > run-time. Some framework ideas that I have incountered have interactions of > this nature all over the place so that, for IDL compilers which do not > support the "import" type method, one might as well keep everything in one > large IDL file. > Once some developer starts taking advantage of the "import" methodology, > that developer has locked his code to that ORB. Thus, there is no > portability. #pragmas can also present similar problems, but at least the > OMG has stated that if the pragma is not for a particular compiler, then it > is to be ignored. You cannot, however, ignore #include. > > -----Ken Geisinger > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 916-758-9850 jeffm@visigenic.com +1 415-312-5158 >From soley Mon Nov 25 07:51 EST 1996 Date: Mon, 25 Nov 1996 07:51:32 -0500 From: soley (Richard Mark Soley) To: orb_revision Cc: kegeisi@clark.net (Ken Geisinger) Subject: [kegeisi@clark.net: Portability and the #include directive] Content-Length: 3815 Although Ken didn't send this issue to the ORB CORE revision committee, this is likely where it belongs -- disambiguating "#include" would be a good thing! Now that the RTF is back up and running, I submit that the RTF should consider this issue for cleanup in the 2.1 core. -- Richard Date: Sat, 23 Nov 1996 15:41:19 -0500 (EST) To: orbos@omg.org, issues@omg.org From: kegeisi@clark.net (Ken Geisinger) Subject: Portability and the #include directive I have asked about this before but got no real responses on this. So, I'm trying again: I have investigated a couple of ORB products and have found what I consider to be an alarming discrepancy in the way these products treat the #include direction in their IDL compilers. I do not know if any work has been done or any discussions have occurred concerning this problem, but I truly believe that, if this issue is not resolve, we will never attain portability among ORB products. The current release of ICL's DAIS supports the notion that #include has the same definition that C and C++ programmers have grown accustomed. That is "include means to insert the code contained within the identified file and proceed with the compilation as if all of the code is in the same file. This, of course, generates the client and implementation code for the IDL for all interfaces, etc contained in the file(s). DAIS also currently supports an "#import" directive which tells the compiler to be aware of the definitions in the files, but do not generate code for it. "#import" is not part of OMG IDL. Digital's ObjectBroker (version 2.5) also supports the "traditional" notion of #include. It supports compile time flags as to which object implementation code is to be generated during the compile. Client code, however, can only be generated in one shot. This did make compiling a framework's worth of IDL somewhat awkward. I know that Digital has taken some measures to simplify their IDL compiler since version 2.5, but I am not aware of what exactly they did. IONA's Orbix can support the "traditional" notion of #include or treat it as DAIS's #import directive by a compiler switch flag. A possible problem is that it becomes an all or nothing option. I'm not saying it's a bad idea. I just want to lay as many of the cards out as I am aware. Thanks to Steve Vinoski, I have been made aware that HP treats #include at global scope as merely introducing declarations, i.e., no code is generated for such #includes. If on the other hand an #include appears at non-global scope, e.g., inside a module, then it gets textually included and code is generated for it. An interesting idea that may merit closer examiniation. The basic problem is this. If you are developing a framework, there may be instances where interfaces will need to exist that allow the exchanging of CORBA objects from one implementation to another. It would be extremely useful if the interfaces can be designed so that only objects of the specific type can be passed and that this checking can be done at code compile time (in C++, etc...) or in the local process space of the client at run-time as opposed to always in the receiving object implementation at run-time. Some framework ideas that I have incountered have interactions of this nature all over the place so that, for IDL compilers which do not support the "import" type method, one might as well keep everything in one large IDL file. Once some developer starts taking advantage of the "import" methodology, that developer has locked his code to that ORB. Thus, there is no portability. #pragmas can also present similar problems, but at least the OMG has stated that if the pragma is not for a particular compiler, then it is to be ignored. You cannot, however, ignore #include. -----Ken Geisinger >From mail Mon Nov 25 10:12 EST 1996 From: Joe_Sventek@HP-PaloAlto-notesgw1.om.hp.com X-Openmail-Hops: 1 Date: Mon, 25 Nov 96 07:13:11 -0800 Subject: Re: Portability and the #include directive To: Orb_Revision@Omg.Org Content-Length: 678 Item Subject: Lotus Notes Message Text Despite what may be stated in the CORBA 2.0 specification, the original intent for #include semantics (I wrote the original IDL specification) were what is implemented in the HP ORBplus product - i.e. it has "import" semantics if used at global scope (can be used to introduce various identifiers and types without generating any code) and has "normal" include semantics if used in an inner scope. If people have problems with this, then I would suggest adding an import declaration to IDL, preferably without the leading '#', to indicate exact import semantics. This would free up the #include for the "normal" semantics. Joe Sventek >From mail Mon Nov 25 11:11 EST 1996 Date: Mon, 25 Nov 1996 11:02:32 -0500 (EST) From: Jishnu Mukerji To: Orb_Revision@Omg.Org Subject: Re: Portability and the #include directive References: <"18774:1*"@MHS> Content-Length: 1536 Excerpts from Org.OMG.orb-revision: 25-Nov-96 Re: Portability and the #in.. Joe_Sventek@HP-PaloAlto- (679) > Despite what may be stated in the CORBA 2.0 specification, the original > intent for #include semantics (I wrote the original IDL specification) were > what is implemented in the HP ORBplus product - i.e. it has "import" > semantics if used at global scope (can be used to introduce various > identifiers and types without generating any code) and has "normal" include > semantics if used in an inner scope. > If people have problems with this, then I would suggest adding an import > declaration to IDL, preferably without the leading '#', to indicate exact > import semantics. This would free up the #include for the "normal" > semantics. Furthermore, I think this presents us an excellent opportunity to deep six this whole C++ cpp based breandeadness and replace it by something that addresses specific problems in the IDL. For example, I think that the use of #pragma to introduce Repository ID prefixes (and UUIDs) is an abomination. We should have extended the IDL in some reasonable fashion to do this. Similarly, get rid of this #include stuff and replace it with IDL primitives to "import" etc. Also the naming convention of IDL files needs a makeover while we are at it. Of course all this has to be done in an evolutionary fashion allowing a smooth transition over years to the more rational new scheme. But we should start working on what the new more portable scheme is. Just my $0.02 ..... Jishnu Mukerji >From mail Mon Nov 25 19:50 EST 1996 Date: Mon, 25 Nov 1996 19:46:49 -0500 (EST) X-Sender: kegeisi@clark.net To: jmischki@wheel.dcn.davis.ca.us (Jeffrey Mischkinsky) From: kegeisi@clark.net (Ken Geisinger) Subject: Re: Portability and the #include directive Cc: orbos@omg.org, issues@omg.org, ian_foster@iclosi.com Content-Length: 6186 Okay, three out of four vendors have seen fit to support the "#import" style semantics. All 3 are in technical violation of the CORBA2.0 specification. My view on this is that these vendors see a need which is not addressed by the specification. I, too, see the need for the same thing. So, how about it? Do any other ORB vendors out there also see the need for the "#import" style semantics? After all, they are the ones who are writing most of the CORBA "compliant" code these days. What about us end-users? Anyone out there taking advantage of these features in their ORB of choice that would hate (dislike) loosing this feature? I know that one of these vendors, until recently, was considering dropping support for this feature since it was not "CORBA compliant." My biggest concern is that if discussion doesn't start now, a good idea could be lost. ---Ken Geisinger >> >> I have asked about this before but got no real responses on this. So, I'm >> trying again: >> >> I have investigated a couple of ORB products and have found what I >> consider to be an alarming discrepancy in the way these products treat the >> #include direction in their IDL compilers. I do not know if any work has >> been done or any discussions have occurred concerning this problem, but I >> truly believe that, if this issue is not resolve, we will never attain >> portability among ORB products. >I agree that this is issue that needs to be addressed. >However, I believe that the current CORBA 2.0 spec is pretty clear on the >meaning of the #include directive. It states that "Text in files included with >a #include directive is treated as if it appeared in the including file." >The "alarming discrepancy" you note is caused by the fact that many vendors >have chosen not to implement these semantics. While I agree that there are >in fact good reasons for wanting/needing #import-style semantics and even for >arguing that the #include semantics as specified in the spec are broken, >the current spec is actually quite clear. > >But until there are compliance tests, things like this will be an issue. Again >there are really 2 issues: a) If your favorite ORB vendor doesn't implement >the spec and you want portability, then ask them to. and b) If you think >the current spec is broken, deficient, etc. file an issue and then agitate >to have it addressed. > >The situation is a bit more complex for the following reason. >Actually the spec says OMG IDL preprocessing is based upon C++, and that >"A complete description of the preprocessing facilities may be found in The >Annoated C++ Reference Manual, Chapter 10.) So according to the spec, a >"real", i.e. OMG conformant compiler has to support all the preprocessing >stuff that is part of the C++ std., essentially cpp. So an IDL compiler isn't >using cpp, or equivalent, it doesn't correctly implement the spec. To the >extent that many vendors don't implement the syntax and semantics specified >in the spec, users have got a portablity problem. >> >> The current release of ICL's DAIS supports the notion that #include has >> the same definition that C and C++ programmers have grown accustomed. That >> is "include means to insert the code contained within the identified file >> and proceed with the compilation as if all of the code is in the same file. >> This, of course, generates the client and implementation code for the IDL >> for all interfaces, etc contained in the file(s). DAIS also currently >> supports an "#import" directive which tells the compiler to be aware of the >> definitions in the files, but do not generate code for it. "#import" is not >> part of OMG IDL. >> >> Digital's ObjectBroker (version 2.5) also supports the "traditional" >> notion of #include. It supports compile time flags as to which object >> implementation code is to be generated during the compile. Client code, >> however, can only be generated in one shot. This did make compiling a >> framework's worth of IDL somewhat awkward. I know that Digital has taken >> some measures to simplify their IDL compiler since version 2.5, but I am not >> aware of what exactly they did. >> >> IONA's Orbix can support the "traditional" notion of #include or treat it >> as DAIS's #import directive by a compiler switch flag. A possible problem is >> that it becomes an all or nothing option. I'm not saying it's a bad idea. I >> just want to lay as many of the cards out as I am aware. >> >> Thanks to Steve Vinoski, I have been made aware that HP treats #include >> at global scope as merely introducing declarations, i.e., no code is >> generated for such #includes. If on the other hand an #include appears at >> non-global scope, e.g., inside a module, then it gets textually included and >> code is generated for it. An interesting idea that may merit closer >> examiniation. >> >> The basic problem is this. If you are developing a framework, there may >> be instances where interfaces will need to exist that allow the exchanging >> of CORBA objects from one implementation to another. It would be extremely >> useful if the interfaces can be designed so that only objects of the >> specific type can be passed and that this checking can be done at code >> compile time (in C++, etc...) or in the local process space of the client at >> run-time as opposed to always in the receiving object implementation at >> run-time. Some framework ideas that I have incountered have interactions of >> this nature all over the place so that, for IDL compilers which do not >> support the "import" type method, one might as well keep everything in one >> large IDL file. >> Once some developer starts taking advantage of the "import" methodology, >> that developer has locked his code to that ORB. Thus, there is no >> portability. #pragmas can also present similar problems, but at least the >> OMG has stated that if the pragma is not for a particular compiler, then it >> is to be ignored. You cannot, however, ignore #include. >> >> -----Ken Geisinger >> >> > > >-- >Jeff Mischkinsky >jmischki@dcn.davis.ca.us +1 916-758-9850 >jeffm@visigenic.com +1 415-312-5158 > > >From mail Mon Nov 25 20:18 EST 1996 From: Michi Henning Subject: Re: Portability and the #include directive To: kegeisi@clark.net (Ken Geisinger) Date: Tue, 26 Nov 1996 11:14:55 +1000 (EST) Cc: jmischki@wheel.dcn.davis.ca.us, orbos@omg.org, issues@omg.org, ian_foster@iclosi.com Content-Length: 924 > Anyone out there taking advantage of these features in their ORB of choice > that would hate (dislike) loosing this feature? Yes. The import semantics are particularly useful for a large spec that breaks into several (more or less independent) subsystems. By #including subsystem IDL at the appropriate place, you don't end up dragging all of the stub code into clients who only use a subset of the interfaces. I think the best way to resolve this is to specify corresponding behaviour in the spec. As you point out, several vendors considered the issue serious enough to break with the standard, so what should be fixed is the standard, not the ORBs in my opinion... Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html >From mail Mon Nov 25 23:30 EST 1996 Date: Mon, 25 Nov 1996 22:27:00 -0600 From: Brian Vetter To: Ken Geisinger Cc: Jeffrey Mischkinsky , orbos@omg.org, issues@omg.org, ian_foster@iclosi.com Subject: Re: Portability and the #include directive References: <199611260046.TAA10348@mail.clark.net> Content-Length: 628 Ken Geisinger wrote: > So, how about it? Do any other ORB vendors out there also see the need for > the "#import" style semantics? After all, they are the ones who are writing > most of the CORBA "compliant" code these days. What about us end-users? > Anyone out there taking advantage of these features in their ORB of choice > that would hate (dislike) loosing this feature? While not an ORB "vendor", we have an ORB. Instead of the #import style, we chose #pragma to provide similar function. As a consumer of our ORB, we would be lost without it or a similar function (well, maybe not lost). Brian Vetter bjv@tivoli.com Sender: jis@fpk.hp.com Date: Thu, 11 Feb 1999 17:19:04 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: orb_revision@omg.org Subject: Issue 306 re #include Is this something that the RTF can do anything meaningful about? Or do any of you suppose that we could try to convince the Components submitters to fix this once and for all by introducing a proper "import" thingy in IDL? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Sender: ecobb@svlhome2.beasys.com Date: Thu, 11 Feb 1999 14:23:01 -0800 To: Jishnu Mukerji , orb_revision@omg.org From: Edward Cobb Subject: Re: Issue 306 re #include Cc: corba_compnts@expersoft.com (Components Submitters List) Jishnu, I think we, the components submitters, are like to do as you suggest.. At 05:19 PM 2/11/99 -0500, Jishnu Mukerji wrote: >Is this something that the RTF can do anything meaningful about? Or do >any of you suppose that we could try to convince the Components >submitters to fix this once and for all by introducing a proper "import" >thingy in IDL? > >Jishnu. >-- >Jishnu Mukerji >Systems Architect > >Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, >Tel: +1 973 443 7528 300 Campus Drive, 2E-62, >Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > ************************************************************** Ed Cobb, Technical Director, Systems Architecture BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8910 E-mail: ed.cobb@beasys.com ************************************************************** Date: Fri, 12 Feb 1999 09:12:06 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: orb_revision@omg.org Subject: Re: Issue 306 re #include Organization: Triodia Technologies On Thu, 11 Feb 1999, Jishnu Mukerji wrote: > Is this something that the RTF can do anything meaningful about? Or do > any of you suppose that we could try to convince the Components > submitters to fix this once and for all by introducing a proper "import" > thingy in IDL? I'm all for a language construct to deal with #include. The sooner we get rid of #include, the better. As far as Ken's issue is concerned, personally, I couldn't care less what the compiler does if a #include appears not at global scope. The issues for separate compilation this creates are too complex to be even worth thinking about. For #include at global scope, I think we have semantics that work, it's just that it is implementation-specific whether code is generated for the included file or not. 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 Date: Thu, 01 Apr 1999 14:09:59 -0500 From: Ken Geisinger Organization: Concept 5 Technologies To: orbos@omg.org Subject: Issue 306: include semantics I don't know where else to send this, so I thought I'd send it to the lead TF for Core issues. Back in November 1996, I filed an issue with the OMG concerning the symantics of the include directive in IDL processing. To summarize, the specification states "text in files included with a #include directive is treated as if it appears in the included file". However, many ORB vendor treat the symantic as "required definitions to complete those in the including file are found in the included file" (page 3-10 of CORBA 2.2). So, either most ORB vendors have non-compliant IDL compilers or the specification should change. I am unable to find information as to which RTF this was assigned or what was the resolution, if any. The CORBA 2.3 RTF report does not address the areas of my concern. This issue is still important to me in that it is hard to build portable code if the ORB vendors products inconsistently treat the requirement imposed in section 3.3 of the Core specification. But, now I am wondering if this is a language specific issue. The Ada language mapping specifies a different semantic for the include directive on page 23-11. For JAVA, it just doesn't matter since class files are generated and there can't be name collisions. In the C specification, it specifies "all OMG IDL compilers will, by default, generate a header file named Foo.h from Foo.idl..." (page 19-29). I have not explored the other language mappings in any detail. So, it seems the specification in chapter 3 is not quite right. Should it say something like: "IDL compilers search the included files to ensure the definitions in the including file are complete. The handling of the included file is specific to the target language of the IDL compiler." For C, add the following to the second paragraph in section 19.24: "If Foo.idl included definitions from other IDL files (via the #include directive), complying implementations can have "Foo.h" include the header file generated specifically for the included IDL file." For C++, it should be clear that C++ follows the same rules for included IDL as C. The end goal is to prevent identifier clashes in the target language. -- --------------------------------- | The opinions expressed above Ken Geisinger | are my own and not necessarily Sr. Software Integration Engineer | those of the company to which Concept Five Technologies, Inc. | I am employed. --------------------------------- |