Re: Passing Parameter as Variable vs as address of variable

Hello Daniel,

Am 26.08.2023 um 18:41 schrieb Daniel Gross <daniel@xxxxxxxx>:

Von meinem iPhone gesendet

You typed and formatted/quotes all of that on a miniature screen? :-O

Thanks for your efforts!

When looking at your assertion from a "modern hardware" point of view, counting wall clock time, I agree. The difference is negligible. Double the amount of some µs is still some µs. Too fast for a human being to be detected.

If I get it right - both passing a pointer as a value or passing a variable by reference is the exact same thing - from the machine code view.

In both cases a pointer to the original variable/memory space is passed on the stack to the called procedure.

But it’s different from the compiler view - for a parameter passed by reference the compiler can do a type check. But it cannot do that for an arbitrary pointer. That’s why C has „typed pointers“.

If your assumptions are correct, then the actual naming "by value" and "by reference" seem to be misleading to me.

Otherwise, see my answer to Vern. Data is duplicated implicitly before a pointer to the duplicated data is passed to the callee. *Where* it is duplicated, doesn't matter. It is duplicated, and this is the performance penalty price you pay.

A use case for me to "pass by value" is to "write protect" a variable. The called application now can alter the variables' contents at will. It won't get changed for the calling application.

Altering parameters that a passed to a procedure is generally „bad style“ - only if passed by reference and with full intention.

Yes, but programming is done by humans and humans make errors. :-) A pass by value could be understood as "safety measure", in this regard.

If a procedure receives a parameter by value and you modify that, this is very convenient - but also confusing.

Maybe I should provide some more context here…

I'm writing programs in old style positional RPG IV, also because I mainly use a very old OS release. I admit, I have not yet looked in depth into "true" functions within one source member. Handling functions seems to me much more cumbersome and noisily (more lines of code) in RPG compared to C. So I usually just use subroutines and necessarily stick to loads of global variables.

This means, there is no variable scoping, and inadvertent change of variables within the program flow is a constant source of corner cases to catch.

"Expensive" program functions I put into completely separate applications. Example: PGM1 is mainly an SFL to choose things. PGM2 is then called with some identifier as parameter. The identifier is derived from the SFL selection before. If PGM2 calls for another SFL display, putting all the logic for two SFLs into one source member yields comparatively large and complex program.

If PGM2 uses the passed identifier, and within the program flow, changes the identifier (because of a programming error), this will for sure affect how PGM1 continues to work after control is passed back.

In any way, I agree that modifying the memory location being passed to a "secondary" program (by reference) to get output (or error indications) back is bad style. So far I've worked around this by careful designing applications sitting on the call stack being "independent" in error handling and report directly to the user.

In C, retval = dothis() feels very easy.

In classical RPG, probably old enough to when there is no EVAL, I guess messages are involved. A topic I constantly fail to wrap my head around. Once I thought I understood messages to be a much more elaborated version of what I know as UNIX signals. But after reading some more, I'm not so sure anymore.

But maybe there are other ways to get the described "readonly" feature.

Yes there is the „const“ keyword for parameters. Under normal circumstances the parameter is read only but passed as reference if the parameter type and the passed variable type are fitting. If not, a temporary copy with the right type is generated and passed by reference.

Anyway - with „const“ you have write protected parameters which are past fast by reference - and the compiler deals with the read only thing.

Thanks for the hint! Need to look into this, and if it's already available with V4R5.

:wq! PoC