RE: Large Return values (was Re: Variable Length Field Question)

-----Original Message-----
From: rpg400-l-bounces+srichter=autocoder.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+srichter=autocoder.com@xxxxxxxxxxxx]On Behalf
Of Hans Boldt
Sent: Thursday, May 20, 2004 1:41 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Large Return values (was Re: Variable Length Field
Question)


Steve Richter wrote:
>>(BTW, improving the performance of large aggregate return values is a
>>future objective.)
>
>
> Is IBM going to use the method I posted at the beginning of the year on
the
> rpg yahoogroups list? My idea is to add two new features to RPG. one is to
> auto dealloc a pointer returned from a proc.  The 2nd is to let the
compiler
> know what a return pointer points to.
> ...

>No.

>The ideal way to handle this would be some method that doesn't
>require any source code change. If that's not possible, the next best
>thing might be a new keyword on the procedure prototype that tells
>the compiler to use a different interface under the covers.

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.

-Steve