RE: Pointer suggestion -- RPG400-L

Hi Alan,

<snip> Also, as to using pointers. My opinion only but returning pointer is very poor programming practice assuming this is coming from a service program. I can't think of worse way to implement a service program than returning a pointer. I have just written a memo in our office, that my boss will not release, about this entire subject. </snip>

Hmmm...

Firstly, I didn't advocate using a data pointer as a return value from a subprocedure. I offered the suggestion that a data pointer could be used as a parameter, passed by value. Of course, the calling procedure could still pass the %addr() of a variable instead - the callee doesn't really care unless it is required to manipulate the memory allocation directly.

If memory allocation is never to be done within the callee then I can't see any difference in the following scenarios: 1) A data variable passed by reference. 2) A pointer initialised to the data variable passed by value. 3) A pointer allocated memory and the value of a data variable assigned to it and then passed by value.

(this is, of course, ignoring the fact that the third scenario will not result in the original data variable being changed by the callee - effectively making it a pass-by-value data variable)

OK, at a system level there is a difference - in the first two the memory is assigned at program initialisation, and is assigned from static storage - assuming the variables are global, otherwise the variables are automatic and the storage is allocated from the stack when the subprocedure is called. In the third example the memory is allocated from the heap. But at HLL there's no difference. The way the data is passed will not change. The way the data is manipulated by the callee will not change. The way the data is returned will not change. In fact, there is no way within the callee to determine whether the data passed is an internal address of a variable, a data pointer assigned the value of the address of a data variable, or a data pointer containing the address of a copy of the data variable. So I can't see a problem in utilising any of the three options above to suit your needs.

Now, if we're talking about memory allocation then that's another matter entirely. I can see why any programmer wouldn't want to pass a pointer to a procedure that allocates memory to it. But this can be very useful in some circumstances, in other circumstances it may be more prudent to register a call-back procedure and handle all memory allocation internally. The point is to note that there are options available.

But, if you mean to change the world then I'd suggest you send your memo to Rochester and Toronto, because I can't think of many useful APIs that DON'T take pointers as parameters.

I mean, try using iconv() to translate 256kb of ASCII data to EBCDIC without passing it two pointers (together with ints for the data lengths). :-)

Cheers

Larry Ducie