Protected parameters, 2nd try_(re)

Mon, 10 Mar 1997 15:01:49 GMT

Peter Gerwinski wrote:

> [...]
> It needn't be an explicit assignment; it might be a call to a function
> which makes the value of `x' change.  To pass everything by value *is*
> the only possibility.

I must admit, I didn't think of these cases.

> But I will modify `Const' parameters to pass small things by value and
> to work with implicit temporary variables when a constant is passed as
> a `Const' parameter.

You mean, for big things!? I don't think you need any temporary variables
for small things that are passed by value, regardless whether a variable,
constant or an evaluated expression is passed. For big things passed by
reference, you need a temporary variable if a constant or expression is
passed, I think.

> Then it's up to the programmer to take care that
> the `Const' parameter doesn't change its value due to side effects.

Then it would be like Borland's. However, speaking from a purist's point of
view, I can see the problem that it would be implementation-dependent whether
a parameter is passed by value or by reference. This means it is "undefined"
whether side-effects can happen or not. Would it be permissible (well, const
parameters aren't standard anyway, I mean in the "spirit" of the standard)
to leave that undefined, or would it be necessary that const parameters have
clear semantics concerning side-effects?

> Hmmm ... how to tread `protected Var' parameters???

As far as I understood it up to now (Berend, correct me if that's not what
the standard says), "protected" only means that the compiler must make sure
that the parameter isn't altered, and never changes the way of passing the
parameter.

That would mean:

'const' parameters would be used if the programmer is sure that there can't
be any side-effects (which is true in the majority of cases, e.g. if the
procedure operates only on local variables and will not be called with the
same parameter twice; or e.g. if the procedure reads the value of the
parameter only before it writes to any var parameters and/or global
variables and/or calls any procedures/functions that do), and wants the
compiler to choose the most efficient way of passing and to verify that the
programmer doesn't accidentally alter the parameter.

'protected' parameters would be used if there is a danger of side-effects,
and the programmer only wants to verify the parameter isn't altered, putting
up with a possible inefficiency. (I think it's rare that side-effects become
a problem, especially with big structures where the inefficiency would
matter.)

'protected var' parameters would be used in the (very rare, IMHO) case that
there could be side-effects, and the programmer *wants* these side-effects to
influence the parameter. E.g., I could imagine a procedure that watches some
variable for changes, but must not change the variable by itself - perhaps
in a multi-threaded program where another thread could modify the variable -
just fantasizing...
-- 
Frank Heckenbach, Erlangen, Germany
heckenb@mi.uni-erlangen.de
Turbo Pascal:   http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

Frank Heckenbach (heckenb@mi.uni-erlangen.de)