On 07/07/2011 18:14, Alexander Klenin wrote:
On Fri, Jul 8, 2011 at 04:06, Florian Klämpfl<flor...@freepascal.org> wrote:
Am 07.07.2011 19:00, schrieb Alexander Klenin:
Currently, there are four meaninigs of "const":
1) "Const by value" -- like Integer
2) "Const by reference" -- like shortstring
3) "Const by reference, but not really const" -- like objects
4) "Const by value, excapt rare breakage" -- AnsiString
(and interfaces, but let's not touch that can of worms in this thread :-) )
I propose to remove meaning (4).
Unlogical. 2) and 4) are coupled.
This whole construct is unlogical. Logically, "const a" should mean
just "assignment to a is a compile-time error".
But this is not achievable due to compatibility reasons.
Still, I suggest that (4) is a (small, but still) evil, and sould be removed.
Slightly fresh start.
I do believe the feature itself is a valid feature (the ability for the
programmer to tell the compiler to skip something like ref counts)
There is a similar feature (via compiler switch) to skip implicit
exception frames. (With the risk of mem leaks, and what else, if
incorrectly used.
The current naming may not be the best, since it implies a point of view
different from the real meaning.
But the current naming is already there, shall we really make everyone
who used the feature correctly, change their code, because some others
did not?
Wouldn't that be to punish the ones who got it right.
I don't oppose having compiler switches, and/or directives, to defined
the exact kind and extend of the const behaviour, so people can choose
the one they like.
- But I can see, that those who maintain the overall compiler-code will
cry out in pain, in expectancy of what there will be to be maintained...
- And I am not sure, if any other more correct definitions can be done
(The problem is, I am not sure, if any other design, does not end up in
splitting hairs, due to the overlap of tightly coupled issues....)
I agree the fact that objects are not const, if passed as const is not
consistent. But if that was to be fixed, then objects had to be made
real const too (rather than further weaken the entire thing)
Anyway back to strings.
I would not oppose (but I am not sure if sensible either) if the
behaviour for strings could be modified by compiler switch or directive.
To prove or disprove the sense in that, will take a lot of tiny steps,
and see , if in the end they all make sense. And I will not go into that
discussion....
Just some ideas what all might have to be considered, extremely
incomplete list of ideas. Maybe easy to dismiss at first sight, but
before dismissal they would have to be tracked down a long way, to every
possible extend. Feel free to dismiss them, I have no intend in proving
them.
- You mentioned interfaces, well there are dyn-array ref counted too and
no copy on write. So the earlier example I tried to make on strings
(with the caching of expressions) it would probably apply to dyn arrays...
Which means trying to change the feature, would create even more and
more special cases... (or alternatively for all time forbid certain
optimizations like caching certain results...)
- const should avoid to copy data (only data that is smaller or equal to
pointer is passed as value). But strings with refcount will be copied
(if the other/global var with the same data is changed). So adding a
refcount, means making a copy of the data. Which is fundamentally
against the stated indent of not copying it...
....
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
