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

 PE>> to avoid confusion.  Remember that every single function is

 PE>> declared as inline, and Borland won't inline things with

 PE>> "for", "while" etc in it, whereas it looks
like IBM will go

 PE>> for broke.  BFN.



 PM>> So, based on your figures, when compiling with the

 PM>> optimiser turned on, Borland compiles 56 times faster (9

 PM>> secs versus 505 secs), it produces code that is 25% the

 PM>> size (30K versus 120K), and that runs only 7% slower (41

 PM>> secs versus 38 secs), is no doubt cheaper and is a lot more

 PM>> straight forward to install (see below). The Borland

 PM>> compiler sounds like a real bargin doesn't it. Pity about

 PM>> the bugs in it though.



 PE> Once again, I must stress that this test wasn't particularly fair, and I

 PE> happen to like the fact that it spent a long time trying to optimize my

 PE> program instead of just "she'll be right mate".  Since all these

 PE> functions were being inlined, it is understandable that the executable

 PE> would be bigger. Since they were being inlined and subsequently

 PE> optimized, it is understandable that it would take longer to compile.  As

 PE> for the 7% slower, well the bottleneck in the code (from memory) was,

 PE> like most of my programs, in about one line of code, which couldn't be

 PE> done faster even in assembler (something basic like adding 10 to a

 PE> pointer and looking at one character), so the compiler only had the rest

 PE> of the program to optimize.  Perhaps you've got a program you could put

 PE> through both compilers?



Fair enough that it should take longer to compile, but 8 minutes is
ridiculous. If the bottle neck is on one line, how is C Set++ generating
the code that makes it quicker?



I don't have any programs big enough to give any useful comparison of
compile time, but maybe you should try compiling Emacs. Mind you, with the
speed of C Set++, it could take you all weekend :-)



 PM>> INSTALLING IBM C SET++



 PE> I think I'll give this note to someone at IBM, to see if they want to

 PE> take your comments into account.



Hopefully they'll do something about it.



 PM>> A (rather small) box lands on my desk today. At last I can

 PM>> do some useful work, thinks I, after hitting my head

 PM>> against the brick wall known as Communications Manager

 PM>> (I'll save my rave about this product for another time) for

 PM>> two weeks trying to get it to talk LU 6.2 to the

 PM>> mainframe.



 PE> But once you've done it, remember that you can have square brackets, and

 PE> live in C paradise (C with square brackets on MVS).



LU 6.2 is for talking program to program, in our case OS/2 REXX to
mainframe CICS. What you're talking about is the emulator session (also
known as LU 2), which we've been running since the machine was set up. The
PC I'm using currently isn't mine, so I won't get any chance to use square
brackets on the mainframe. Besides, there are other programmers that need
to maintain the code on a dumb terminal.



 PM>> I opened the box and searched though the small number of

 PM>> manuals and bits of paper (IBM has this fixation on soft

 PM>> copy manuals) to find the installation steps. It talks

 PM>> about Workframe/2, the Toolkit and the compiler. Well, I've



 PE> And it's pretty difficult finding that little piece of paper which

 PE> basically means "start here, this is the most important
one".  I went

 PE> looking at some of the other manuals first, and gave up and looked at the

 PE> other stuff.



Yep, this is pretty much how I stumbled across it. They should have printed
it it bright colours and have large letters across it.



 PM>> packet of disks and the last ones are in the first packet),

 PM>> the README file pops up to keep me amused. It says that if

 PM>> you are going to program in C++ and, on the off chance you

 PM>> want to use NULL in your programs, you have to edit one of

 PM>> the header files and fix it up. Now obviously, using NULL

 PM>> in a C++ program is a rare occurance, since this wasn't

 PM>> picked up during the testing of the compiler. Maybe I'm



 PE> Yes, I found that strange, and decided to ignore it.



I though you were into C++ now. I figured that even though I probably
woulnd't be using C++ at work, I'd make the change now just in case since
I'd forget about it later.



 PM>> Finally the install has finished! Er, hang on, what are

 PM>> these three disks I still have left over? They are marked

 PM>> "Toolkit Debugger" or some such. Now I remember saying

 PM>> during the compiler install that I wanted the debugger

 PM>> installed, so what's going on here? I found a manual that

 PM>> describes this (appears to be a debug version of the OS/2

 PM>> kernal) but there are no install instructions in the

 PM>> manual. Look on the disk, and find a "DBUGINST" (surprise,

 PM>> surprise).



 PE> Hmmm, can't remember what I did with that.



If you find a use for it, let me know.



 PM>> [NOTE: at this point in my rave, OS/2 decided it had had

 PM>> enough of me knocking IBM and it terminated my editor (who

 PM>> said OS/2 wasn't a clever operating system). Luckily my

 PM>> editor keeps a back up and I only lost the last line. Back

 PM>> to the story...]



 PE> You can download emacs from me, did you know it is free for commercial

 PE> use? 32-bit OS/2 version even.  Compiled with BC++ for OS/2!



Well, this is the first time my editor has abended under OS/2. after the
third time, I had a closer look and found the first abend had left some
garbage characters in the backup file that were confusing it. When I
deleted the garbage it stopped abended. Can't explain the first one though.



After using EPM at work to do some C programming, I'm almost ready to give
Emacs a try :-)



 PM>> Open the box and throw away the install guide. Put the

 PM>> first disk in, type "INSTALL" (Borland) or "SETUP"



 PE> Yes, I fail to see why IBM's couldn't have been the same.

 PE> Paul



We're lucky we didn't get SMP/E for OS/2 :-)





Paul



--- GoldED 2.40