Newsgroups: comp.windows.ms.programmer
Path: utzoo!utgpu!watserv1!mims-iris.waterloo.edu!tom
From: tom@mims-iris.waterloo.edu (Tom Haapanen)
Subject: Borland C++ 2.0 impressions
Message-ID: <1991Apr1.122952.17519@watserv1.waterloo.edu>
Sender: daemon@watserv1.waterloo.edu
Reply-To: tom@mims-iris.waterloo.edu (Tom Haapanen)
Organization: WATMIMS Research Group, University of Waterloo
Date: Mon, 1 Apr 1991 12:29:52 GMT
Lines: 64

I've now had Borland C++ 2.0 (aka bcc) for almost two weeks, and finally had
enough time to get our application compiled with it.  I benchmarked it against
our existing Microsoft C 5.1, for compile time and executable size.  I didn't
check executable speed, as with many Windows apps it's rather difficult to do
that.  Here are the options that I used for the test:

	# Borland C++ 2.0
	CC     = \usr\bcc\bccx
	OPT    = -O -Z
	CFLAGS = -mm -W -w-rch -w-par -a -Hu $(OPT) -I..\inc\ -o$(OBJ)/$*

	# Borland C++ 2.0 --- no optimization
	CC     = \usr\bcc\bccx
	OPT    = -O-
	CFLAGS = -mm -W -w-rch -w-par -a -Hu $(OPT) -I..\inc\ -o$(OBJ)/$*

	# Microsoft C 5.1
	CC     = cl
	OPT    = -Ox
	CFLAGS = -nologo -Mm -K -Gw -Zp $(OPT) -FPi -I ..\inc\ -Fo$(OBJ)/

And here are the results that I got, compiling 2500 lines of headers and
25,000 lines of source on a 386/20 (4 MB RAM, QEMM 5.1, tkernel hi=yes,
583K free DOS memory, 1048575 free for bcc), excluding link and rc:

				bcc	    bcc -O	cl -Ox
	Compile time:		14:05	    15:23	25:41
	Executable size:	312K	    311K	268K
	Minimum load size:	236K	    236K	216K

The Microsoft alternate floating-point library cuts out another 17K from
the C 5.1 executable and minimum load sizes.

Now, for some more subjective observations, both positive and negative; these
are from the Windows development viewpoint, and ignore the C++ side of things
completely:

+ bcc has very fine-tunable warning level control
+ bcc compiles about 50% faster
- bcc produces an executable about 20% larger
- bcc has no alternate floating-point library available
- bcc can't disable that d*mn copyright banner
- bcc's msc emulation has some bugs: at the minimum, the _MAX_PATH and
  associated constants are wrong, and no makepath() function is provided.
  This can be easily fixed, but it's a pain.
- bcc doesn't know about environment variables
- bcc doesn't like the MKS Korn shell; if using the shell, it needs to be
  invoked with a full backslash path (\usr\bcc\bccx), as it gets confused
  by the slash path the shell generates (/usr/bcc/bccx).

And as to the Whitewater Resource toolkit:
+ cut and paste available for bitmap/icon editing
+ string, accelerator and menu "editors"
- include files can't be used
- no status box is available for dialog editing
- WRT is a resource hog!

The lack of include files is enough to prevent me from using WRT.  I expect
we'll use bcc for development work, but the final code is still going to get
compiled with Microsoft C, giving us smaller code and access to the alternate
math library.

[ \tom haapanen --- university of waterloo --- tom@mims-iris.waterloo.edu ]
[ "i don't even know what street canada is on"               -- al capone ]