[fpc-devel] Const optimization is a serious bug

[Martin]

On 05/07/2011 19:28, Alexander Klenin wrote:
> On Wed, Jul 6, 2011 at 05:12, Martin<fpc at mfriebe.de>  wrote:
>> TStringList could be made save, and keep the const. Just add additonal
>> references where needed.
> Agreed with your analysis. This still feels like a wrong design to me
> -- spreading complexity

It's the wrong usage. it shouldn't be used everywhere, then it wouldn't 
be spread everywhere. the problem was to many people not knowing.

It should be used with the same care and low frequency has move or 
fillbyte is used. like "move(string1, string2, sizeof(pointer))", very 
dangerous, but in a few places it may have it's place (TSringlist moves 
the list of strings (the actual pointers, not the char-data)


>>> Note that the only reason TString/TStringList does not break too often is
>>> that
>>> the only way to get access to an element is by calling Get, which
>>> increments refcount
>> Not getting this part?
> Suppose somebody implements "const Result" as I suggested in the link
> I posted. Then the code like
>
>    strLst.DelimitedText := strLst[0];
>
> will cause the same problem.

Not necessarily

strLst.DelimitedText  could hold the new value in a temporary/local var (which would add a refcount) to ensure it does not go away.

And before strLst.DelimitedText overrides the old strLst[0], it has a refcount from strLst[0] =>  conclusion, if correctly done, it would still be safe.

But again. using const, is like using move or fillbyte on string pointers. The implementer has to know that


> Alternatively, suppose somebody adds TStringList.ForEach(AVisit:
> TVisitString) method,
> then similar problems will be in the visitor procedure
>
> procedure VisitString(const AStr: String);
>

Why? As long as the value is in the list, it is referred to by the list?