Re: Adding pointers to RPG language.

[boldt@xxxxxxxxxx]

Jon wrote:
> >>  RPG is better suited to applications, which are generally I/O bound.
> >>  It all falls back to using the right tool for the job.
>
>Agreed 100% Hans - which in many cases is _exactly_ why pointers are
needed
>in the language!!
>
>If you are IO bound in a batch process which handles millions of records
and
>does a gazillion validation look-ups, the ability to use bsearch (or your
>own binary search) on a based array is not just useful but in many cases a
>life saver.  One customer we worked with used these kinds of techniques to
>slash their main batch process time by well over 50%.

I don't mean to belabor the point, but I do have some nits to
pick with your argument.  I agree that anything to reduce the
number of I/O operations is a good thing.  Looking at I/O
offers the biggest "bang for the buck" when it come to
performance tuning.

But how important are pointers to that effort?  Do pointers
help?  Are pointers necessary for performing a binary search?
No, not really.  Not even if you use the C run-time function
bsearch, if you code it properly.  Pointers might possibly
make use of bsearch easier in some cases, but they're not
necessary.  And as of V5R1, you don't even need bsearch.  The
new built-in function %LOOKUP uses a binary search algorithm
when used with ordered arrays.

My basic argument is that pointers are not necessary in true
high-level language programming.  I'll repeat what I said in
a previous note:  Pointers are the "goto" of data structures.
In fact, many modern high-level languages have neither gotos
nor pointers, in consideration of the reality that both are
generally more trouble than they're worth in the realm of
application programming.

Oh BTW, here's a great quote I found while wandering the net:
"One should always use the right tool for the right job; for
example, one should never use a big wrench to pound in a nail,
when a little wrench will work just as well..."  ;-)

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com