dg@lakart.UUCP (David Goodenough) (04/26/89)
I recently got a copy of BDS-C V1.6 for my CP/M machine, and thought
I'd pass on my opinions of the system.
In general I am very pleased with the package, a lot of the library
"inconsistancies" from earlier versions have been fixed (fopen for one,
and the way printf("%s", "") works). For those that have not used it
it takes a couple of goes to get used to the absence of static variables,
but other than that, it is a very good implementation. For speed of
compilation it is blindingly fast. There was a review in Byte a while ago
benchmarking various CP/M C compilers, and BDS-C was consistantly (read
every time) the fastest, typically compiling in half the time required
by the others.
Included with the system is full source code for _ALL_ the libraries, so
you can hack what you don't like - for example I find the 5/C:FILENAME.EXT
system for user numbers a real irritant, so after a bit of messing I was
able to change the system to recognise C5:FILE format. The libraries
include not only the standard ones, but there is a floating point math
library, long integers math library, DIO (directed I/O - provides
redirection / pipes just like UNIX) etc. etc. etc. and code to expand
wildcards in the command line (so PROGRAM B:*.C will get an argv / argc
that you'd expect - with all the filenames in it).
In addition, there is a Z-system version (all comes in the same
package - it's four disks all up: DSDD, so if you've got a Kaypro 2
or an Osborne1, you are in for a real surprise), that supports named
directories, and a whole raft of other Z-features.
However, the real cat's whiskers is CDB. Apart from the fact that it
doesn't show the source code from within the debugger, I found it about
as good as DBX / CDB under UNIX. You have statement level execution
control - it even understands that:
a = 5; b = strlen(fudge);
is two statements, and will execute them as separate steps. You have
named access to your local and global variables, and useable expression
evaluation. _AND_ for those that really want to see the source from
within the debugger (I sure as hell would like it :-) ) the source
_OF_ CDB is provided, so you can hack it. Of course, it makes a sizeable
dent in your TPA, using typically 20-25K, but for debugging C programs
it's a whole lot more civilised than ZSID.
You also get RED, a text editor which can be set up to "eat" an error
file produced by the compiler, and show you what you did wrong in the
compilation. This is a fair text editor, and again source is provided.
From what I saw of it, it's quality stands up beside CDB and the
compiler package in general, my main reason for not using it is it's
size (something like 40K) and my familiarity with my current editor.
However from a reviewers perspective, I would say RED is a well written
editor, and due to it's configurability can be adjusted to suit anyone's
tastes.
All in all I would rate this as a very good compiler indeed, well worth
the money.
--
I have no connection with BD Software, who wrote the BDS-C system;
nor with Sage Microsystems East, from whom I purchased it.
I just think it's a damn good package.
--
dg@lakart.UUCP - David Goodenough +---+
IHS | +-+-+
....... !harvard!xait!lakart!dg +-+-+ |
AKA: dg%lakart.uucp@xait.xerox.com +---+