|
Hans, Would you mind explaining what advantage an IBM-implementation of say... "%toupper()" built-in function would provide over a programmer-written "toupper()" procedure? For example, would a long returned value be an issue, would it be language independent, would it have any performance implications? -Bob -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Hans Boldt Sent: Friday, May 21, 2004 6:52 AM To: rpg400-l@xxxxxxxxxxxx Subject: Re: Large Return values (was Re: Variable Length Field Question) 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 is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
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.