Alexander Klenin schrieb:
Martin, I do not know why you and Hans suddently have an urge to insult Chad,
but he really did not deserve this.
Perhaps a threshold was reached, when the same wrong argumentation was
refrained too often.
As for the whole "optimization hint" angle, I'd like to note that:
1) This is contrary to previous posts in this same thread, where
FPC developers insisted that "const" semantics is defined as
"no refcounting", which is quite different from a hint.
Refcounting is one optimization aspect, passing large data byref another
one.
2) If "const" is indeed an optimization hint, that places it in the
same category as,
say, "inline". What would you say if adding "inline" keyword to a procedure
converted working program into randomly crashing one? I'd say this
is optimization bug,
much like the title of this thread.
IMO the situation is very different for "inline". Both optimizations
have very little in common (from the compiler VP).
3) Current documentation (http://www.freepascal.org/docs-html/ref/refsu58.html)
declares that "const" modifier is "retaining the semantics of
passing by value",
so there is definitely a bug here -- you can declare it to be bug in
specification, but still.
Sorry, I cannot find anything like this statement in the link. The
addressed byval/byref move doesn't change the semantics, provided that
the item is not modified in user code - this can be verified for records
or other simple types by the compiler.
The situation is very different for parameters, which already *are*
references. In these cases the passed object can be modified, regardless
of "const", the compiler only checks that the reference *itself* is not
changed.
The situation is different again for *managed* types, which also are
always passed byref. Here the removal of refcounting applies.
On the more constructive note, I have yet another proposal:
1) Leave current "const" implementation broken as-is.
2) Introduce new "constval" modifier which is similar to "const",
but guarantees correct "by-value" semantics.
If you want to introduce different keywords, then please different for
beforementioned cases. E.g.
constval x: integer; //all value-types
constref r: Trecord; //also ShortString
const??? o: TObject; //all references, except following
const??? s: AnsiString; //all managed types
BTW the "constref" keyword has been introduced for *external*
subroutines (MacOS ABI), which require that a value is always passed by
reference, independent from SizeOf(param) and SizeOf(pointer). Its use
should be restricted accordingly.
3) Slowly migrate existing code to either "constref" or "constval",
use "const" for legacy/compatibility/extreme optimization cases.
<IMO> "const" is already used far too often in the FPC/Lazarus
libraries. The compiler instead should treat it as an error, when an
unmanaged (object) reference is used with "const".
It's kidding when somebody requires that the compiler prevents him from
inadvertently modifying an given value parameter. He who doesn't have
enough coding discipline to care for such restrictions himself, will
make more logical errors that no compiler can detect.
When the meaning of "const"/"constref" is documented as kind of a
*calling convention*, that allows the compiler to optimize the code, no
more discussion is required.
</IMO>
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
