dmh@JULIET.CALTECH.EDU (David M Hull) (06/02/86)
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 <portab.h> - >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 <portab.h> file for each compiler/system/whatever, and *leave the .c files alone*. Thus #define BYTE char once and for all. <flame on> 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.) <flame off> >*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!
tim@ism780c.UUCP (Tim Smith) (06/02/86)
In an article dmh@JULIET.CALTECH.EDU (David M Hull) writes: > > But not fork(), wait(), getenv(), setenv()? Sounds like about par >for the microcomputer C course (which is not /so/ bad). > I knew some people once who were implementing a UNIX(R) library for a Mac C compiler. One of them wanted to provide fork() like this: fork() { errno = EAGAIN; return -1; } This should also work for the ST... :-) -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim
braner@batcomputer.TN.CORNELL.EDU (braner) (06/06/86)
Got Megamax C a few days ago, and it was worth the wait. VERY GOOD MANUAL!! I'm using it with Micro C-Shell, 1040ST and RAM DISK. Compile and link time: about 15 sec (2-page program)!! Problem: Megamax have their own I/O redirection feature built in, as does C-Shell, but both do not work (on programs compiled with Megamax) from the C-Shell environment... The 32K segments are for quicker execution, using word-size offsets. You can use arrays of any size if you malloc() the space. Catch: the OS Malloc (GEMDOS call) is full of bugs (although it DOES accept a long argument, which standard C malloc() doesn't), while the Megamax malloc() only gets 8K at a time from GEMDOS according to the manual. (And does not return any to GEMDOS to avoid the bugs...) (It may be 8K or more, I havn't tested it yet. But the argument is unsigned (16 bits), so 64K max...) A more serious bug (for me): floating point comparisions (e.g. "if (a<b) ..." where a, b are float) don't work right for negative numbers. Given the promise of "full FP support" that's SERIOUS! (I'm sure they'll fix it, though...). On the good side, you can choose (at link time) whether the FP operations will be done in single or double precision.