gwyn@smoke.BRL.MIL (Doug Gwyn) (03/18/90)
In article <53605@microsoft.UUCP> roberth@microsoft.UUCP (Robert HESS) writes: >Orca C also has some problems. I don't use it much, but I have had system >crashes during editing, and compilation. While I haven't ever had ORCA/C crash like that, it is definitely true that Release 1.0 has enough bugs that it is quite difficult to use with much existing application code, e.g. what you might try to port from a UNIX environment. (Don't port AT&T's UNIX sources, however, unless you have proper licensing.) >I have also heard that it doesn't strictly follow K&R C, Well, I should hope not. ORCA/C is advertised as an implementation of the ANSI C standard, although as of Release 1.0 it is missing some pieces and deviates from the standard in a few ways (apart from bugs). >for example this will compile fine: > void main ( int argc, char *argv[]) >...but these variations will fail: > void main (argc, argv) > int argc; > char *argv[]; > void main ( int argc, char **argv) I haven't noticed any problem with old-style definitions. > Orca C does allow true INLINE codeing. And although I haven't tried it > yet, it looks pretty good, with actual assembly directives and labels. 99 times out of 100, when you feel the urge to mix assembly language with a higher-level language like this, you're better off maintaining the assembly code as a separately-assembled subroutine in its own source file. (The exception is when you really need to rotate bits in a word as fast as possible, or some other rather specialized case like that.) > As I remember, there were a couple routines that I ran across that Orca > C didn't have access to. ORCA/C Release 1.0 did not include the hooks for tool calls that were new with Apple IIGS System Disk 5.0; a future release will, though. > TML also sells a separate package of source code examples called > "TML Source Code Library II" (for about $50). ByteWorks also sells C source code for additional UNIX-like utilities, as does 360 MicroSystems and undoubtedly some other companies. > In Orca, they tell you to write your NDA as a regular program, > then once that is working, make a few modifications to it to turn it > into an NDA, then copy the program to the Desk.Accs folder and reboot > your machine to test it. Yikes! a little severe. Oh, good grief. If you have one of the "load desk accessories" NDAs installed, you can obviously use that to load the NDA being tested. ORCA/C supports four program flavors (EXE for APW/Orca shell environment, SYS16 for Apple desktop environment, CDA, and NDA). If you know anything about the details these environments you should realize that your program needs to be structured somewhat differently depending on the target environment. > Orca is able to use the normal APW command scripts to perform 'make' > type functionality. The Orca desktop environment is by default configured to allow simple compilation and execution without resorting to APW/Orca shell commands. For more complex applications one does in general benefit from using a shell script or one of the commercial APW environment "make"-like utilities (I think I got mine from 360 MicroSystems). The Orca linker is not scriptable, however, so if you need that capability (which one seldom does), you'd have to use the APW linker. At least they're compatible. > Orca has their own editor that they wrote. It does not allow user > selectable fonts, in fact, the font it uses is not one you will find > anywhere else. But this allowed them to tune their editor graphics > specifically around this font, and frankly, I am amazed at how fast > it is. It is a good editor, but occasionally (under circumstance I haven't quite nailed down) I find that it loses large chunks of my source file, usually appending portions to the end of the file. If you happen to notice that this has happened before initiating SAVE FILE, you can avoid clobbering your file on disk (only the memory buffer is corrupted). Otherwise, you need to resort to keeping backup copies just in case. I don't know whether or not ByteWorks has found a way to fix this bug for future releases. (I'm going to port "sam" anyway, which will be tricky given a one-button mouse.) >| Do they compile the standard language? > Orca does not appear to be fully K&R yet (as noted above). That's irrelevant; C is now defined by the ANSI standard. As previously noted, ORCA/C attempts to conform fairly closely to the standard, but falls a bit short at present. Its main lacks are: Preprocessing support for # and ## operators Several library functions and headers, e.g. <signal.h> %p format specifiers are taken to indicate "Pascal strings", not pointers Basically, it implements a subset of the standard at present.