I am proud of all you propeller heads that stuck with me the last five months as we compared the C and COBOL languages.  This month is our last installement, and contains very little 'meat' compared to previous months. Last month we talked about I/O in the two langauges, this month is pretty much wrap up.  For those of you who missed the previous months, go back and read the four issues of Interact previous to this one.

CODE SKELETONS

OK, so just what do you have to do to write a program in C?  As you know, COBOL has it's four divisions that must be used;

 IDENTIFICATION DIVISION
 ENVIRONMENT DIVISION
 DATA DIVISION
 PROCEDURE DIVISION

Each of this has it's own purpose in life as to what it describes.  In C everything is based on the function.  As you saw in my previous example I had 'main()' towards the top of my program.  You can think of main() as the PROCEDURE DIVISION.  It is a function just like everything else in your C program will be, and it is usually the only function you MUST have. I say usually because if you are writing a series of subroutines that are  going to go into an RBM you don't need to name function main().

So to write the classic 'Hello World' program in C, this is all you would need to do.

#include <stdio.h>
main();
 {
  printf("Hello World\n");
 }

That is a lot less code than it would take under COBOL, but it's still more than you would have to do in BASIC.  The problem that I see here is that having to do the include of stdio.h just for the one printf() statement, cause's your program to be fairly large for something that is so trivial.

CODING FOR PORTABILITY OR SPEED

You hear a lot about how portable C is, and how you should code for portability. Let's be honest, how many of you are really concerned about moving your application across various platforms?  The only real portability I would be interested in is MPE V to MPE/iX.  There are just so many things that change from platform to platform that it could be really tedious to code for portability.

COBOL on the other hand is incredibly portable, especially if you are using something MicroFocus or Acucobol, both of which run on dozens, if not hundreds of platforms unchanged.  Of course this portability comes at a cost, since the compiliers don't generate true executables, but p-code that has a run time interpreter.

If you code to take advantage of your CPU's native architecture you will see a great increase in speed and reduced code size.  If you code for portability by using the languages native constructs you will have a larger, slower program. If you want the best of both worlds you will want to code your own intermediate include files that allow you to switch between architectures. A good example is the file I/O intrinsics, if you always call my_fopen you can change what my_fopen does, call the MPE intrinsic FOPEN or the UNIX version, or even HPFOPEN for MPE/iX.

The last method is probably the preferred way to code if you want the best of both worlds.  It isn't a trivial amount of work however, so seriously look at if you are interested in ultimate portability or not.

SUMMARY

So what do I conclude from all this?  I would never ever write a user application system in C on the 3000.  The language is just to cumbersome to handle most of what you want to do (in my opinion), and is just to foreign to the architecture. You have terrible record structure handeling, NULL's in all your strings that if you aren't careful will end up in your data base.  I would however use it for any of those special little subprograms that you use to use SPL for. C++ is a better C,  and you don't have to use the OOP stuff in it if you don't want to, but to date the only C++ available on the HP is the freeware GNU one, but it will only run  under POSIX.  Make no mistake though, C++ takes at least a year to beome at all profecient at for the average programmer, and two years before you are really good.  PASCAL wouldn't even be a bad choice, especially PASCAL/XL, although a creative C programmer can make their code look exactly like PASCAL if they want to, of course the only reason to do this would be to get around PASCAL's stringent type checking, but have the syntactic constructs.

Last month I mentioned that I would need a Christmas column, but if my estimates  are correct, then this issue will be the Christmas one.  Those of you who have been contributing during the course of this series to the column will start to see your contributions starting in '97, and if no one contributed, then this will be the last installement of this column for a while.  And to reiterate what I said at the beginning of this series;

"There may be some very minor error's in my code examples, they are meant to illustrate a point.  So those of you who know something I don't, please keep the hate mail to a minimum, but all useful, constructive, and friendly input is appreciated."