On 05/07/2011 19:28, Alexander Klenin wrote:
On Wed, Jul 6, 2011 at 05:12, Martin<f...@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?
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
