Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!cmcl2!harvard!caip!lll-crg!nike!cad!ucbvax!JULIET.CALTECH.EDU!dmh From: dmh@JULIET.CALTECH.EDU (David M Hull) Newsgroups: net.micro.atari16 Subject: Megamax C mini-review Message-ID: <860602034528.001@Juliet.Caltech.Edu> Date: Mon, 2-Jun-86 06:45:28 EDT Article-I.D.: Juliet.860602034528.001 Posted: Mon Jun 2 06:45:28 1986 Date-Received: Wed, 4-Jun-86 00:28:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 112 In entry #761 (5/31/86) ditzel@ucbvax.berkeley.edu (Charles L Ditzel) writes: >I recently received Megamax C and my first impressions are very favorable. I found this review to be generally useful and informative. I may indeed acquire this system for my work, if it's as good as it looks. Below are various comments, questions, gripes and flames. >Editor: >The editor that is supplied is from acceptable to good. I *really* >disliked the editor supplied with the Atari/DRI development package. >The megamax editor is quirky on two points: find and the arrow >keys - if these are editor quirks and not my own doing. On the basis of what features do you reccomend the megamax editor over micro-emacs (I assume this is what you mean by the atari/DRI editor)? Why did you dislike micro-emacs? A statement like the above is next to useless. >Unix compatible routines: >abs,atof,close,toupper,tolower,_toupper,_tolower,toascii,creat,isalpha, >isupper,islower,isdigit,isalnum,isspace,ispunct,isprint,iscntrl,isascii, >exit,_exit,fclose,fflush,ferror,feof,clearerr,fileno,fopen,freopen,fread, >fwrite,fseek,rewind,ftell,getc,getchar,fgetc,getw,gets,fgets,lseek,malloc, >free,calloc,open,printf,fprintf,sprintf,putc,putchar,fputc,putw,puts, >fputs,rand,srand,read,sbrk,scanf,fscanf,sscanf,setbuf,setjmp,longjmp, >strcat,strncat,strcmp,strncmp,strcpy,strncpy,strlen,strtol,atal,atoi,ungetc, >unlink,write But not fork(), wait(), getenv(), setenv()? Sounds like about par for the microcomputer C course (which is not /so/ bad). >C compiler: >I had program (written with DRI C) that put up a menu bar and window >it ported in 10 or 15 minutes. Of that time 95% of the time >was spent in the editor. The main problem stemmed from >using some of the unportable #defines from DRI's - >BYTE, LONG, WORD.. Megamax C complained...about the DRI RCS generated >C code using these keywords...i changed these to the more portable char, >long,int and all was well...The compiler is pretty fast (tho' i >have a one megabyte ST which helps :) You're joking, right? The whole idea behind DRI's "mandatory coding conventions" ;=| is that you make one silly file for each compiler/system/whatever, and *leave the .c files alone*. Thus #define BYTE char once and for all. Whether this is all worth anything is another story. In particular, it seems that their LONG declaration is often better served by (void *) (which may even become standard if people take a liking to implementing standards --- ANSI has put massive amounts of work into this type of stuff --- unsigned char's and the lot.) Seeing LONG used to mean (type *), like in the gem manual makes me somewhat ill. C supports high level distinctions like "A long is not necessarily a pointer and vice-versa". Why shoot yourself in the foot with such a neanderthal convention? My developer's package came with two versions of APSKEL.C --- atari's and DRI's. The main differences were: 1) DRI's worked --- it redrew the window at the right time. Atari's was somewhat fractured when it came to updating. 2) Atari's had comments like (I quote from memory) /* #include this to insure incompatability with all known systems */ or somesuch at the top of portab.h, and /* Storage wasted for idiotic bindings */ after the declarations for intin[] and company. While I agree with atari's sentiments, I find it disturbing that they managed to introduce bugs into a working program. Also, one (or both) of the versions had constructs like wind_update(TRUE); where you just have to know that TRUE means 1 (fortunately this is the non-zero value that everyone picks) and that 1 means either begin update or end update (fortunately context makes this clear, /if/ the code is correct). You tell me why they didn't just #include the proper file and be done with it. A magic number is marginally more legible than a meaningless manifest. (By the way, wind_update has /four/ meaningful input values, not two, as suggested by the use of TRUE), but a well chosen #define beats the shit out of both. Moral: The preprocessor is /your friend/, if you let it be. But (alas) it seems that no one wants to take the trouble to use it responsibly. (I will now duck as legions of responsible programmers pelt me with rocks and garbage. Of course /my/ code is always flawlessly perfect.) >*space used by a program at run time is divided into a number of segments. >Each segment may contain up to 32KB. Is this a bug or a feature? As a survivor of the /wonderful/ world of the 80x86, I would tend to think bug. Does this actually mean something more humane and useful? Is there any way to get a huge array (>64K)? Thanks again for the review. -- dmh (It's about the New Genre) P.S. I will be disappearing from netland in a couple of weeks (I'm graduating), so get your digs in quick!