ken@oresoft.UUCP (Ken Cramer) (10/18/88)
Oregon C++ is not only a C++ compiler but a full ANSI C standard conform- ing system. As such, it must provide its own header files and set of li- brary functions which are ANSI conforming. This is because very few, possibly none, of the host systems on which Oregon C++ may eventually run, support ANSI C and the full set of library functions and header files that it requires. Note that aside from various facilities required to support C++, Oregon C++ supplies just the facilities proscribed by the ANSI standard - no attempt is made to replace other host functions or li- braries, or prevent their use. Under Oregon C++, when the link step is performed, the host loader first searches the Oregon C++ library, then the standard C library (/lib/libc.a) to resolve any remaining references (generally low level, system dependent functions). The fact that these two libraries contain functions with the same name opens up a set of potential bugs which depend on the structure of the host standard C library, and which show up during the link step. When these types of problems are reported to us, a workaround can be devised and is communicated to the customer. For the Version 1.1C release of Oregon C++, only one such problem has been reported - one dealing with the malloc function - and the workaround was very simple: use the 'ar d <libname> <x>.o' com- mand to remove the object modules malloc.o and realloc.o from the Oregon C++ runtime library. Note that aside from this problem (and problems yet to be found), Oregon C++ when running on the Sun is fully compatible with the host compiler and libraries. Source code compiled with the Sun C compiler can be mixed with that compiled with Oregon C++; functions in /lib/libc.a other than those defined by ANSI can be used; Sun object libraries can be linked with programs developed and compiled with Oregon C++. A few restrictions are mentioned in the release notes for the product (Version 1.1C) - for instance, the file containing the main program must be compiled with Ore- gon C++ - but these can't be regarded as very serious. Given the probable, eventual widespread acceptance of the ANSI C stan- dard, and the stated desire of Bjarne Stroustrup to eventually base the underlying semantics of the C++ language on ANSI C, we think that custo- mers are better served by the current Oregon C++ approach. Obviously, adherance to a standard makes it easier for users to port software from one system to another. We are very interested in learning of similar host compatibility problems encountered by customers - since they may be correctable in future releases. *************************************************************************** Ken Cramer Oregon Software Inc, 6915 SW Macadam Ave, Portland, OR 97219-2397 Supplier of the only commercial UNIX C++ compiler and Source-Level Debugger. EOM ...!tektronix!oresoft!ken or ...!uunet!oresoft!ken (503)245-2202
tonyw@microsoft.UUCP (Tony Williams) (10/19/88)
In article <247@oresoft.UUCP> ken@oresoft.UUCP (Ken Cramer) writes: > [omitted] >files that it requires. Note that aside from various facilities required >to support C++, Oregon C++ supplies just the facilities proscribed by the >ANSI standard > [omitted] Hey, yes. Let's have parsers that only accept syntax errors, compilers that only implement the deprecated features of Fortrash 8X etc. I like it, I like it. :-) To be serious, I liked the tone and content of your reply. Tony disclaimer...