|
-----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
As an Amazon Associate we earn from qualifying purchases.
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.