Re: parameters - const, value, reference

On Fri, 20 Jun 2003, Richard B Baird wrote:
>
> here's what I THINK I know so far:
>
> 1. const means you are passing the value and don't expect it to change or
> need it to be returned when the function ends.
>

const means you're passing by reference, not value.  Otherwise, you're
right.


> 2. you specify value if you want it passed by value, if you don't specify,
> you pass by reference.

Yep.

>
> 3. if you pass by reference, it takes up the same space in memory, so there
> is no 'moving' of data - the proc doesn't allocate it's own space for it,
> rather it uses the space allocated by the calling pgm.  (I assume the
> caller passes a pointer to the procedure)

Yep.

Well, technically it passes an address to the procedure.  An address is
just a number that specifies a byte in RAM.  A pointer is a type of
variable designed to hold an address.  Similar to the concept of
2003-06-20 is a date, and D is a type of variable designed to hold a date.

>
> under what circumstances is passing by value better than by reference?
>

Unfortunately, "better" is a subjective thing.   What's better will
be different, depending on what you're trying to do.

Consequently, I answer this type of question by explaining how they work,
and letting you decide which one is better.

Okay...  Subprocedures have their own "automatic" memory.   This memory is
given to them when they start, and freed back up when they end.   That's
where all their "local" or "automatic" variables are stored.

The way parameters work is to copy data from the caller's memory to the
subprocedure's automatic memory.

If the variable is passed by VALUE, the contents of the parameter are
copied from the caller to the subprocedure.   The key word here being the
*contents* of the variable.

If the variable is passed by REFERENCE, the address of the parameter is
copied from the caller to the subprocedure.   The key word here being the
*address* of the variable.

Now, when you change your subprocedure's copy of the parameter, is where
the difference becomes critical.   With VALUE, the contents were copied
into your new variable.  So what happens if you change those contents?
Well, they're different in your subprocedure, but unchanged in the
caller's copy.

But, when you passed by REFERENCE, what happened?  Since an address was
passed instead of a value, the address is used to REFER TO (that's why we
call it reference) the memory that was allocated to the caller.
That means when you change the variable it's directly changing the
caller's copy!

What about CONST, you say?  Well, CONST is a different way of saying
"read-only reference."   The parameter is passed by reference, but you're
not allowed to make any changes to it.  Thus, "read-only."

So, the effect is this:

   If you want to use this parameter to return data to the caller, then
   pass it by reference.

   If you need to change your local copy only, or if the variable is
   smaller than 16-bytes long, pass it by value.

   If you don't need to change it at all, and it's larger than 16-bytes
   long, pass it by "read-only reference", aka CONST.

(I should explain that "16-bytes" business.  An address on the iSeries is
16-bytes long.   Thus, when passing by reference, the system always copies
16 bytes from the caller to the subprocedure.   So, value should be
quicker for variables smaller than 16 bytes, and reference should be
quicker for variables larger than 16 bytes.)

(Another thing that I should mention is that copying memory is one of the
fastest operations a computer can do, so don't dwell too long on the speed
issue of copying 16 bytes vs copying 4 bytes.  However, when passing 32765
bytes vs 16 bytes, there's a noticable difference)

Now, just to make things more complicated :)  we've got some
more considerations to add to the list:

   When calling a PROGRAM (as opposed to a procedure) you MUST pass by
   reference.   CONST is allowed, as that is still by reference.

   Some languages, notably C, do not allow you to pass character strings
   or arrays by value.  If portability to other languages is a concern,
   you should pass these by reference/const.   (i.e. if a C program is
   going to call yours, he'll have trouble passing a 10-char string by
   value -- though there are ways to work around that...)

   When passing by either VALUE or CONST the compiler knows that you
   will not be changing the variable, and therefore will automatically
   insert code to convert from one variable type to another, or allow
   you to use expressions, etc as appropriate.

> would you always specify const if you don't need or want the proc to change
> the data sent?

I do my best to specify either VALUE or CONST for a parameter that will be
input-only to my subprocedure.

    1) It makes the code more self-documenting.

    2) It makes debugging easier...  if you know a procedure CAN'T change
        a variable, you can skip over it when trying to figure out
        why the value is wrong :)

> in what instances would you not specify const for these types of
> parameters?

When I specify VALUE :)

>
> can you mix value and const on the same parameter?

No...  think of CONST as "read-only reference."   Reference and value are
opposites...  since CONST implies reference, it would not make sense to
be able to specify both value and const at the same time.

Hope that helps.