Re: Is const really that much better than value?

Joe Pluta wrote:

Okay, first I see basically two kinds of calls in the world, calls to
programs and calls to procedures. I get a little fuzzy on the difference
between a bound procedure and a procedure in a service programs; as far as I
can tell, the difference lies more in the resolution of the procedure
address than in the parameter passing.

I was using "bound procedure" in the general sense. A bound procedure can be "statically bound" in the same program, or "dynamically bound" in a service program. I think that when you (Joe) say "bound procedure", you are actually thinking of "statically bound procedure". You are right that the parameter passing is identical for either type of bound procedure.

But now you throw a tiny wrench into this for me. While I rarely use C or
C++, I've run into more COBOL lately and the way I read what you said, you
need a special syntactical construct to allow COBOL to populate the %parms
variable properly is a COBOL program calls an RPG program. And I assume
this would also apply to procedures.

%parms is always correct for program calls from any language. What I said only applies to bound calls. The mechanism that Larry described for program calls is correct; the OS passes an array of pointers and the number of pointers. This is true for OPM and ILE programs.

As I read what you've written, in those cases where you either don't or
can't pass operational descriptors, %parms is meaningless; but does it get a
value?

It does get a value, but you can't rely on it if you can't control the callers. When you use %parms in a procedure where the caller didn't pass the operational descriptor, you are basically asking the compiler to refer to an unpassed parameter. Sometimes it would get an exception (pointer not set or invalid pointer type); in that case, %parms or *PARMS would be -1. But in other cases, there would be a valid pointer there, and %parms would have a nonsense value. (If %parms is used in a subprocedure, it is evaluated at the beginning of the procedure whether or not it is actually used later.)

Here's why I ask: if it at least gets set to the maximum number of
values in the parameter list, then I could make an architectural decision
that all calls that don't use OPDESC must simply include all parameters, and
the called procedure would still work. Whereas if %parms is truly undefined
(or always zero, or something like that), then I would either have to always
call variable parameter procedures with OPDESC (in particular taking care on
COBOL calls) or else somehow test in the called procedure whether OPDESC was
used at all (and I don't even know if that's possible, nor what sort of
overhead it entails).

You don't have to code OPDESC for RPG to pass the operational descriptor. The mini operational descriptor is always passed by RPG for all calls. If you code OPDESC, the compiler will build the "full" operational descriptor which describes all the parameters.

There's no way to tell within the called procedure whether the caller passed the operational descriptor. If %parms is -1 you can be sure they didn't, but if it's any other value, you can't be sure.

For C and C++, you code #pragma descriptor along with your prototype (see QSYSINC/H LEDATE for examples).

For COBOL, you code BY DESCRIPTOR on the call. I don't think there's a way to do it in the LINKAGE section.