|
Steve Richter said: > > There is a problem with passing by const reference that I did not see > mentioned in the recent discussion. > Here's an explanation on why this happens by Hans: --- In RPGIV@xxxxxxxxxxxxxxx, "Carlos Kozuszko" <tidesarrollo@xxxx> wrote: > I think I've read on the RPG redbook that the compiler cannot forbid the > called function to make changes to the data passed. > Once i had a scenario where the value of the passed variable was changed > indirectly (i think reading a file) so the compiler couldn't prevent the > change and the variable's value was changed becouse the address was the > same, i solved this by using VALUE instead of CONST. > ... This is correct. CONST provides an assurance that a parameter passed to a procedure will not be changed by the procedure. The compiler enforces the CONST attribute within the procedure and diagnoses any attempt to modify the passed parameter within the procedure. Also covered are attempts to assign the address of a CONST parameter to a variable. Internally, the compiler may or may not copy the value of the parameter to a compiler generated temp and pass the address of the temp instead of the actual parameter. Generally, if the attributes of the variable passed as parameter match the parameter definition, then the address of the variable is passed. Otherwise, the address of a temp is passed. As pointed out, there may be interesting side effects if the parameter passed is a global variable and that variable is modified within the procedure. Compiler writers call this type of situation "aliasing", where one piece of storage may be addressed by two (or more) different names. In general though, in any programming language it's best to avoid modifying global variables within functions or procedures. I know that's difficult with I/O, but with V5R2, you can use data structures on your I/O statements even with externally described files. Cheers! Hans
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.