RE: the problem with passing a const reference

Carlos,

Thanks for pointing this out.  Hans's response primarily addresses the use
of global variables.  What I am saying is that const can cause problems
whenever the calling proc uses the same variable on more than one parm of a
proc:
   Calc_New_Qty( qty1: qty1 ) ;

 d Calc_New_Qty   pi
 d OutQty                  7p 2
 d InQty                   7p 2  const
  /free
       OutQty    = 0 ;  // this can affect any other pass by
                        // reference parm.  const or no const!
       ...
  /end-free

I think passing any numeric or small char variable by const reference is a
bug waiting to happen.  passing by value is safer and performs just the
same.

-Steve

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Carlos Kozuszko
Sent: Thursday, June 26, 2003 2:57 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: the problem with passing a const reference




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