On Thu, Jul 7, 2011 at 23:09, Martin <f...@mfriebe.de> wrote: > 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.
Have I not just written, in the very detailed manner, that reference counting is a technique specifically designed to prevent this problem? That you code CAN NOT crash, much less for non-obvious reasons, if you use ansistring? That this is a critical advantage of using it, as compared to, say, shortstring? That, finally, the examples with pointers and manual memory management are proving just the opposite of what their author wanted -- i.e. current implementation makes AnsiString no better than PChar in terms of safety? > 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? If you look at the point (2) of the mail you responded to, you will see that I discuss this exact issue. "Const string" is passed by value, and it does not lead to any undefined behaviour and crashes except this case (barring, of course, as-yet-unknown compiler bugs). > 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. How so? If the bug would be fixed, any procedure with "const string" parameter will become perfectly safe, just as with, e.g., "const integer". > Given that the very same code would still be unsafe, even if ref counting > was there, then why put ref-counting in there? I am somewhat unsure what are you talking about here, but if you mean the "const string" parameters, then the statement above is incorrect. > actually constref exists. > but what you seem to want, which is missing: ConstButNotRef Yes, but with less ugly syntax ;-) Maybe "constval"? -- Alexander S. Klenin _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
