robert@isgtec.UUCP (Robert A. Osborne) (05/25/90)
arch@hub.cs.jmu.edu (Arch Harris) writes: >[about Safe C; a C preprossor] >Features include. >1. Real arrays can be delared using the syntax int x.[5]; ^Pascal arrays >Our experience has been the confusion over arrays variables really being >pointer constants is the most confusing aspect of C for our students >learning C. >2. The bool data type has been added,... >3. The `tiny' data type has been added, a one byte integer. >4. An option allows run-time checking of array bounds in safe C's >"real" arrays. >5. A number of other option to provide automatic detection of >pointer misusage. > >Note that none of the changes make safe C less powerful than C. I'm not exactly sure what you are trying to accomplish. If you are trying to teach your students proper programming techniques C is a very poor venue; Safe C isn't much better. It would be better to pick another language (eg. Pascal gives you all the above... for free!). If you are trying to teach your students C then you are doing them a great diservice with Safe C. Any C programmer who doesn't understand the array/pointer business is in REAL trouble. All the other things you will be protecting them against will lead to problems when they are using real C. Safe C will produce a bunch of students who think they understand C; but don't understand some very important basics. This reminds me of a course at UofWaterloo that purported to teach assembly programming. The loops, if/then/elses, subroutines, etc. were all handled by a preprocessor; the only thing I learned was some opcodes for a useless chip and some basic register and stack stuff. UofWaterloo also had a F77 compilier (well, that's what they called it); we ended up with a class that *thought* they could program in F77 (and the ones that already could, like me :-), could no longer). In my opinion, it's very dangerous to teach "close-to" languages, especially to students. Rob. -- Robert A. Osborne ...uunet!utai!lsuc!isgtec!robert or robert@isgtec.uucp