Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucrmath!rhyde
From: rhyde@ucrmath.ucr.edu (randy hyde)
Newsgroups: comp.sys.apple2
Subject: Re: Computer capabilities
Message-ID: <10901@ucrmath.ucr.edu>
Date: 5 Jan 91 06:18:22 GMT
References: <1991Jan4.122840.14246@nntp-server.caltech.edu> <10896@ucrmath.ucr.edu> <1991Jan5.012240.24878@ux1.cso.uiuc.edu>
Organization: University of California, Riverside
Lines: 24

>>A good number of the C++ compilers out there are translators...

I've tried to use CFront with ORCA/C.  Alas, ORCA/C's biggest failing
is that the standard libraries supplied are rather weak.  CFRONT produces
all kinds of calls to library functions which don't exist in ORCA/C.

I've also tried porting a compiler I wrote with FLEX & BISON on a PC
to ORCA/C and ran into the same problem.

To me, this is ORCA/C's biggest problem.  Mike needs to supply a standard
library which is compatible (at least, as much as possible) with Microsoft C
and/or Turbo C.  When this happens, a lot of cross platform compatibility
occurs for free.  Personally, I could live with ORCA/C's slow compilation
times if I could do all my work on my '386 and then port the code across
Appletalk to the GS.  Who cares if it takes a half an hour to compile and
link? I can go back to work on my '386 at that point.  Alas, it's not
quite this simple.  I was spent about 32 hours attempting to get FLEX to
run in native mode on the GS.  I failed.  (Someone else got it to run on
their machine, I downloaded it from BIX, but it failed again on mine).
FLEX is a reasonably machine independent piece of code.  There is no
reason it shouldn't be capable of running on a GS with little or no
effort.  Alas, I failed at it.  If ORCA/C had a better library, things
would be much better on the GS front.
*** Randy Hyde