[fpc-devel] Const optimization is a serious bug

[Alexander Klenin]

On Fri, Jul 8, 2011 at 04:52, Martin <fpc at mfriebe.de> wrote:
> if const reads: I (the programmer) tell the compiler this value is going to
> be constant
> versus: I ask the compiler to help me avoid changing it
> But as in my other mail, it may not be best named (but now we are changing
> topic, it's not about the feature anymore, it's about the name)

Well, that difference is a bit on the of philosophic side in general case,
and, as I said, totally changing the meaning of "const" is not what
I argue for in this thread. (IMHO "const" should mean both).
But, in the specific case of "const string" parameters in FPC,
the problem is that it *already* means both,
and I suspect a lot of code depends on the current meaning.
So this specific case, while maintaining the
contract of "no refcounting on const" runs contrary to the (IMO)
much more meaningful contacts like "adding const increases safety of the code"
and "no memory errors from using ansistrings without messing with pointers".

> But at 2nd sight, I retuned to the example with the caching of expresion
> results.. And If the feature would really mean const "the value of this
> variable will not change, not from within nor from outside this function"
> (and that is what in case of a record (passed by ref) is needed to be real
> const, and allow all the optimization.
I do not quite understand this passage, but did you note that
currently the caching you propose would be unsafe for strings,
but you can make it safe if you fix this bug?
That is, my proposal increases the possibilities for optimization.

> in c++ you can mark an entire method to be const. Means that method can not
> call any thing, that modifies the object.
> If I wanted to go all the way in pascal, then "const x: type" should mean:
> - the compiler allows no modification of x in the procedure (exists in fpc)
> - the compiler allows x only as param, if the param is const too (exists in
> fpc)
> - (new) the compiler prevents calling any other code (any method, procedure,
> or event) unless it has proven knowlege that this code does not do anything
> that could modify the value of x
>  eg only calls to methods that do not modify any variable of the type of x
> at all (and that do not call anything that does...)
Note the distinction here: compiler must only refuse code it knows to
be incorrect,
but must only make optimizations it knows to be correct.
So the right answer for two latter cases is to allow them,
but disable optimizations -- which is exactly what I proposed in the
first place.

> Neither do I advocate  to use const, unless you know what you do..... And if
> anyone advocates it, then it's a problem (but not a problem of the feature)
Just google "const string parameter Delphi" to see the advocating.


-- 
Alexander S. Klenin