Re: Large Return values (was Re: Variable Length Field Question) -- RPG400-L

Steve Richter wrote:

Ideal for who?  The RPG work I do for clients the last few years has been
ground floor, invent the wheel type stuff.  Custom procedures for building
html data streams, wrappers of the os400 and file system APIs.  The feature
I described would work well for me.

The idea of transfering ownership of a pointer from proc to proc works real
well for me in my PC C++ code.  I have a String class and a ReturnString
class. When a String object is assigned to a ReturnString object only the
pointer to the string is copied ( and set to NULL in the from String
object ). The String data is effectively copied from one object to the
other, but since only a pointer is copied, it is as efficient as possible.

Ideal for solving the problem of inefficient returning of varying strings
are adding some simple C++ features to RPG. Actually, just data structure
constructor and destructor member functions. With some simple features like
that there would be no need for a new procedure calling interface.

It sounds to me like you're doing a lot of systems programming, which means you'd probably be better off doing more of your iSeries programming in C or C++. You know how already, and you seem to prefer it!

I don't disagree (much) with what you're saying. My own personal favorite programming language uses "pass by object reference" for parameter passing and return values, and it works quite nicely.

But what you suggest would still require a lot of additional functionality that an RPG programmer would have to learn in order to achieve efficient return of large aggregates from procedures. Ideally, we want the advantages to be available with as little coding as possible on the part of the average RPG programmer. No new syntax would be best, but one keyword on the prototype definition would also be acceptable, we think. Requiring the RPG programmer to think in terms of pointers, constructors, and destructors is right out.

Cheers! Hans

This mailing list archive is Copyright 1997-2024 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.