RE: Pointer suggestion -- RPG400-L

 My apologizes for not responding to this sooner. For same reason, only some of 
the posts are being sent to me. I have been seeing a whole bunch of posts I am 
never seeing by going to the archives. 

<snip>
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.
</snip>

I think there is a couple of issues here. One is that the API's were written 
for a OPM world, not an ILE. IBM did what they did because how else could they 
do it doing a dynamic memory calls and a single point of entrance? If they had 
ILE, would they have written them the same way? 

I could write almost all the API's using ILE functions and not have to use 
pointers. In fact, that is what we it do all the time. We write wrappers for 
System API's that don't need pointers. 

The other issue they are dealing with having to provide compatibility with C 
and everything in the that world is pointer based. The language was designed to 
write operating systems. Nothing but pointers and performance was absolutely 
critical.

The other issue is that the C functions you are talking about were written for 
a pointer based world writing operating systems. . 

My point here is that we have tools in the RPG/ILE world that we don't need to 
do things like passing pointers. I don't see a problem using a pointer inside a 
service program. I have to use them constantly. It is almost impossible to 
write generic service programs without using pointers and dynamic memory. 

In ILE, I can call a procedure to build a list and then retrieve the members of 
that list one by one and have no discernable performance impact. To me the 
whole issue is one of information hiding. If I pass a pointer either direction, 
I now have tight coupling. The caller must know something about the receiving 
program and what it's data structures look like. Change something and all hell 
breaks loose. 

If I pass a pointer to something, how do I know what I have? Is it really a 
pointer to a data structure or to a numeric value? Could be anything. Compiler 
cannot check to see if what we are doing makes sense. 

I admit that the whole problem is a bitch. You want to generically pass or 
return data to a procedure. How do you do it? Pass by pointer, pass a data 
structure, have a function convert to a string value, use exports to export the 
values? I spend hours thinking about these issues. Using pointers looks so easy 
but is filled with danger. I just have to spend time thinking the issues 
through and I invariably find a solution that doesn't require me to use a 
pointer. I am working a dynamic array service program and struggling with these 
issues.  

The reason that object oriented language have evolved is to solve just these 
kind of problems. From the beginning, programming has been evolving from the 
specific to generic. Why did they use pointer in the beginning? Because of 
performance but as the machines get faster and faster, you don't need the 
pointers anymore. We can make a dozen function calls and it doesn't matter. The 
machine is so fast, it doesn't matter. Object oriented languages are just the 
recognition of that. It may take a ton more processing for object oriented 
languages but it doesn't matter. The machines are so fast it drowns any 
difference. If I save a few billions of a second by using a pointer, does it 
matter? When I can make 15 million calls in 27 seconds and hardly make the 
machine even work up a sweat, does it matter if I use a few extra calls?  

I which that IBM could give us one thing in C#. Properties to allow me to hide 
data but still treat it like it was I was doing direct assignment. That would 
solve a lot of problems. 

Again, my opinions only.   

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