PE>> 25 seconds to compile non-optimized with cset++/2

 PE>> 8 minutes 25 seconds for optimized with cset++/2

 PE>> 9 seconds to compile xword6 optimized with BC++



 PM>> What program were you compiling with the IBM compiler? It

 PM>> obviously isn't the same one you used with the Borland

 PM>> compiler.



 PE> Same program, meant to delete the name of the program so as to avoid

 PE> confusion.  Remember that every single function is declared as inline,

 PE> and Borland won't inline things with "for",
"while" etc in it, whereas it

 PE> looks like IBM will go for broke.  BFN.



So, based on your figures, when compiling with the optimiser turned on,
Borland compiles 56 times faster (9 secs versus 505 secs), it produces code
that is 25% the size (30K versus 120K), and that runs only 7% slower (41
secs versus 38 secs), is no doubt cheaper and is a lot more straight
forward to install (see below). The Borland compiler sounds like a real
bargin doesn't it. Pity about the bugs in it though.



At work, I'm doing some OS/2 work for one of the applications teams, to do
with communicating with the mainframe. Since I have to write some C code
they bought C Set++ which arrived today and which I installed. The
installation process leaves a lot to be desired:





INSTALLING IBM C SET++

======================



A (rather small) box lands on my desk today. At last I can do some useful
work, thinks I, after hitting my head against the brick wall known as
Communications Manager (I'll save my rave about this product for another
time) for two weeks trying to get it to talk LU 6.2 to the mainframe.



I opened the box and searched though the small number of manuals and bits
of paper (IBM has this fixation on soft copy manuals) to find the
installation steps. It talks about Workframe/2, the Toolkit and the
compiler. Well, I've got lots of disk space so I may as well install
everything and figure out what it does later. First to install Workframe/2.
I open the packet of disks maked 1 of 1 and find the Workframe/2 disk. Ran
"WKINST" (IBM couldn't go with the flow and use
"INSTALL" or "SETUP").



Going well so far. Next install the Toolkit. The installation steps say to
find the Toolkit manual and look for the install instructions there. Picks
the next disk in the pile. No, thats not the right disk. Opens disk packet
2 of 2. Ah! there it is. Ran "INSTALL" (maybe IBM have seen the
light!) and continued feeding disks in.



Next find the disk of Toolkit updates and run "UPDATETK". This
appears to be some fixes to the Toolkit. Why not just ship the corrected
Toolkit? Then it tells me to manually change my CONFIG.SYS.



Of course, if I want the Toolkit programs to appear in the Workframe menus
I then have to go to a command line and run "ADDTOOL ".



Finally, to the compiler itself. Found the folded piece of cardboard with
the compiler installation steps on it (the compiler manual doesn't contain
the installation steps) and ran "CPPINST" (groan) and start
feeding disks in. Up pops a dialog box saying no previous installation
found. Oh $%^&#$(*&) what's happened now. Read the install guide
which says to ignore this (why bother popping it up in the first place?) as
it just means that I haven't already got a copy of the toolkit on the hard
disk. Surely it would be better to tell me if I *did* have a copy installed
and was about to clobber it. As the machine is busy digesting disks (the
first few of the compiler disks are in the second packet of disks and the
last ones are in the first packet), the README file pops up to keep me
amused. It says that if you are going to program in C++ and, on the off
chance you want to use NULL in your programs, you have to edit one of the
header files and fix it up. Now obviously, using NULL in a C++ program is a
rare occurance, since this wasn't picked up during the testing of the
compiler. Maybe I'm missing something here, but if you're going to update
the disk to put the README file on them, why not just update the disk to
correct the problem in the first place?



Finally the install has finished! Er, hang on, what are these three disks I
still have left over? They are marked "Toolkit Debugger" or some
such. Now I remember saying during the compiler install that I wanted the
debugger installed, so what's going on here? I found a manual that
describes this (appears to be a debug version of the OS/2 kernal) but there
are no install instructions in the manual. Look on the disk, and find a
"DBUGINST" (surprise, surprise).



[NOTE: at this point in my rave, OS/2 decided it had had enough of me
knocking IBM and it terminated my editor (who said OS/2 wasn't a clever
operating system). Luckily my editor keeps a back up and I only lost the
last line. Back to the story...]



While contemplating whether to install these last disks, the guy in the
next work station, who was also installing C set++ (I could tell by all the
obsenities he was muttering), had just tried to install this Toolkit
debugger thing and got some strange error neither of us could understand.
[NOTE: editor is terminated again at this point...] I figured I had had
enough, so packed everything up and went to lunch without installing it.





INSTALLING A BORLAND OR MICROSOFT PRODUCT

=========================================



Open the box and throw away the install guide. Put the first disk in, type
"INSTALL" (Borland) or "SETUP" (Microsoft), select the
components you want installed (which usually defaults to all of them
anyway), hit ENTER and keep feeding disks in.



I think IBM have a lot to learn about "user friendly" software.
[NOTE: once more the editor is terminated...] Maybe they should read their
own manuals about user interface design.





Paul



--- GoldED 2.40