|
Joe Pluta wrote: > ... > The reason I ask is that I'm trying to set up some programming > standards. Should I always pass parameters as CONST (except when they > are truly going to be modified)? Or are there cases (let's say the data > is only 2 bytes long) where it might be more efficient to use VALUE, > because only the actual data is being passed on the stack, not a > pointer. > It is probably more efficient to pass integer/unsigned/float numeric types by value than by reference. But I don't think the difference is really significant enough to bother making a special case. Using VALUE for "large" parameters should be avoided. If it's handy to change the parameter in the procedure, it's more efficient to copy a CONST parameter to local storage than to pass a VALUE parameter. (The system isn't particularly optimized to pass large parameters by value, and I think that's probably true of most if not all systems, so this rule of thumb probably applies on all systems for all languages.) Similarly, returning large values should be avoided, but that's more difficult in RPG - it's nice to be able to return large strings, for instance. So, while it might be "better" to use an output parameter for a large return value, I think I'd tend to take the performance hit to make it easier to call. The reason I would do the extra work for the VALUE/CONST parameters but not for the return values is that a procedure should be as easy as possible to call, possibly at the cost of making it more difficult to write. VALUE/CONST doesn't make any difference coding a call to the procedure, but doing a call with an output parameter (which has to be the correct type) is much ickier than having a return value.
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.