On 07/07/2011 12:42, Alexander Klenin wrote:
I'll re-iterate again:
1) The reference counting is not just an optimization, it is also a
memory management technique,
an important concept which is aimed at providing "simple value"
semantics for heap-allocated structures,
and insulating the programmer from memory allocation details.
If programmer does not do anything obviously dangerous like direct
memory access,
using strings is guaranteed not to cause a whole class of memory errors,
like leaks, double-frees and access-after-free.
Current "const string" implementation breaks this guarantee for the
sake of minor optimization.
It is actually quite ridiculous: "var s: String" *is now safer* than
"const s: String",
I do think Florians, or Mattias example are relevant.
Let's for a moment ignore the const ansistring issue.
The 2 examples prove, that even with "const i : SomeRecord", your code
can crash for none obvious reasons, IF you break the promise, not to
modify the value of I, by modifying the value that you passed in.
That is:
"const x: sometype" for any type (with the exception maybe of those ,
that are passed by value) can lead to undefined behaviour and/or
crashes, if the promise of "const" is broken.
If the above statement can be agreed on (and the examples show this),
then why should the "const ansi string" be a bigger issue?
Yes, the const ansi string breaks the rules that ought to be provided by
ref-counting.
But it only breaks this ref-count promise, for code that is already
unsave, even if ref-counting was in place.
As I have stated in my reply to Mattias, future fpc, could do all short
of optimizations, caching the result of expressions that use only
constants, and const param => the result of such expressions has to be
constant too.
So even if ref-counting was in place. The code was unsafe, because it's
behaviour is not defined, and it's results could randomly change in future.
Given that the very same code would still be unsafe, even if ref
counting was there, then why put ref-counting in there?
because the former can not cause AV, but the latter can.
2) Also, there is a separate-but-related issue that Object Pascal
traditionally conflates
"const" and "reference" semantics in parameters. It would be
significantly better to have
separate "const" and "constref" attributes, but I guess it is much too late.
actually constref exists.
but what you seem to want, which is missing: ConstButNotRef
Nevertheless, currently there are two groups of types in FPC, "simple" types
like numerics for which "const" acts like "passing by value",
and "complex" types for which "const" acts like "passing by reference".
Note that currently "const string" *is passed by value*,
*except when the reference count equals to 1*, when it suddenly
behaves as if passed by reference.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
