|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.