Chad Berchek schrieb:
Some might say that it doesn't matter whether it is passed by value or
reference: if you pass it as const, either way you promise not to modify
it. See, that is my concern: what is IT? People have used other words,
but it ultimately comes down to: if you say the programmer promises not
to modify the thing passed as const, what thing *exactly* is that? A
variable, reference, or instance? With const, we don't really know.
IMO we know that then the data, passed as immediate values on the stack,
shall not be modified by the subroutine. The only confusion was about
const records (and ShortStrings?), when passed by reference. In this
case the content of the referenced record cannot be changed.
When alias are of concern, don't use "const".
With
constref, it means you promise not to modify the memory location
(instance) pointed to by that reference.
Quite useless with objects, which typically are modified by method
calls. Otherwise same as above.
With constval it means
that you can change the memory location/instance that was
passed into the procedure, since the procedure is now using it's own
copy anyway; you just can't modify the instance that the procedure now
has it's own copy of.
IMO that's the normal (non-const) procedure, so far. Any changes to the
passed arguments are invisible after exit from the subroutine.
One additional problem does arise. Constval implies that the
implementation is pass-by-value. However in many (I'd say most) cases it
is quite possible that we could be interested only in the semantics of
pass-by-value, not the implementation. So for AnsiStrings, neither
constref nor constval would be suitable. Constref would mean it must be
by reference, but we want by-value semantics. Constval would mean that
the string has to be copied to a separate memory location, which we
might not really care about, and is slow and wasteful.
That's why copy-on-write was invented. As soon as the data is modified,
a (local) copy is created.
So, I propose: don't have constval literally mean it is passed by value,
i.e.,
pushing the string onto the stack or copying it to a new memory
location. Instead, have constval defined as by-value *semantics*. In other
words, constval would indicate the meaning of the language, not the
implementation. It would not be a calling convention. It would not mean
the call would be by value; it would mean the semantics would be by
value. This is essentially what I originally thought const would mean
with AnsiStrings, though it turned out hazy.
The programmer must know the language and the compiler must implement the
language. How the compiler does that should not determine how the
program behaves.
IMO that's such a weak definition, that it gave birth to this never
ending thread :-(
In the tradition of Wirth, it should be possible to describe the
language semantics by a few implementation details. The implications
*resulting* from the implementation, like alias, are already discussed
in common literature.
See regarding const:
http://www.freepascal.org/docs-html/ref/refsu58.html
The main use for this [const] is reducing the stack size, hence
improving performance, and still retaining the semantics of passing
by value...
(Thanks for the link Alexander!)
This is undoubtedly the most conclusive statement I've seen regarding
this issue. If this documentation were correct, my initial claim that
there is a bug would be correct.
Aliasing is not considered a bug, it's a fact. When a pointer is passed
to a subroutine, it should be clear to every coder that the referenced
memory *can* change during the lifetime of the pointer, even if the
pointer (address) is never changed; the same for all references. When a
coder allows to pass a data structure byref instead of byval, by using
"const", he'll have to accept all the consequences. Since this
difference was the only rationale for introducing "const" into the
language, it has to be accepted as defined, and the documentation should
be updated accordingly.
Effectively the "...semantics..." statement should be dropped from the
docs, and instead the effects of the "const" modifier on *all* affected
datatypes have to be added.
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
