Re: Passing Parameter as Variable vs as address of variable

Hi Patrik,

Von meinem iPhone gesendet

Am 26.08.2023 um 23:52 schrieb Patrik Schindler <poc@xxxxxxxxxx>:

You typed and formatted/quotes all of that on a miniature screen? :-O
Thanks for your efforts!

Thanks - but I‘m from the generation that took a lot of flak in the news groups where you easily got hit by a *plonk* for posting „TOFU“ ;-)

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

Oh - I didn’t make it really clear.

dcl-pr someProc;
parm1 char(20);
parm2 pointer value;
end-pr;

In this case for both parameters parm1 and parm2 a pointer is passed.

So passing a pointer by value and passing a parameter by reference is technically the same.

But in the first case, the compiler can do type checks - in the second case not.

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.

First we have to differentiate between „data“ and „pointers“.

So what happens when:

parm1 char(20);

No data is duplicated - only a pointer to the data is pushed to the stack. Modification of the parameter will be available in the called procedure.

parm2 pointer value;

Also no data is duplicated - only a pointer to the data is pushed to the stack. After dereferencing the pointer, the called procedure can modify the data where the pointer is pointing to.

parm3 char(20) const;

If the variable that should be passed is of type char(20), not data is duplicated - a pointer is passed, but the compiler will take care, that the parameter is not modified in the procedure.

If the variable is of a compatible type - but not the same - like varchar - then a copy of the data is made, and a pointer is passed. And of course the compiler will prohibit a modification of the parameter in the called procedure.

parm4 char(20) value;

A copy of the data is made, and the value is passed directly - no pointer should be involved.

This is the only case where the called procedure can modify the parameter without any consequences for the caller.

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.

Yes - safety is good - because of this we define ALL parameters as „const“ - only parameters that should „pass back“ values are not „const“.

We use „value“ only in very special cases.

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.
<snip>

OK - now that clarifies something.

You’re really missing out a lot. Most things I write are V7R3 and above and **free RPG - because this is what I develop.

When calling „normal“ programs (*PGM objects) then you have to resort to passing by reference. The „value“ keyword is not supported for *PGM calls.

But „const“ is supported - so you can do a lot there.

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.

This is where local procedures (defined in the same member) are handy. Yes you have to type a bit more initially - but you have variable scoping and real parameters - so hell yeah, use it.

"Expensive" program functions I put into completely separate applications.
<snip>
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.

Well - to pass back errors or values you have to other choose if you do dynamic *PGM calls. So „const“ and „no-const“ is your friend to mark parameters as „input only“ or „I/O“.

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

Yes - here we are - create service programs with procedures, and you can have exactly this with procedures outside of your source member.

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.

Message handling is really not easy - especially because „snd-msg“ and „on-excp“ arrived late to the party and one had to use system APIs for everything.

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

Can’t say that - but I really think you should jump ship to a never release if somehow possible.

If only for private interest - PUB400 is your friend. If you company has problems investing in new hardware, then the company behind PUB400 could maybe part of the solution.

Staying on V4R5 is definitely not good - this is so far behind, that somehow nobody can help you a lot.

Regards,
Daniel