On Sat, Jul 9, 2011 at 3:14 AM, Martin <f...@mfriebe.de> wrote: > On 09/07/2011 00:09, Max Vlasov wrote: >> >> The answer is indirect referencing. it's a workaround that probably >> will solve the problem, but I must admit that I don't know what is the >> exact performance price. The compiler when it detects const s: >> ansistring could switch to passing not the actual address of the >> string, but the address of the variable that holds it. In other words >> passing PString instead of string. In this case no reference counting >> or exception frame is probably created and at the same time, if the >> used string is reallocated occasionally because of a side change, the >> code will not fail because it will just automatically use the new >> modified address. >> > > function CRCConstString(constref Str: string): integer; > > does what you describe >
Hmm, it's interesting.. Some observations: - constref is implemented in 2.5.1, right? Unfortunately I can not test it right now in 2.4.2, it refuses to recognize it, but I I want to test it. - In LCL it used only with interfaces and TGuid's, no strings or other structures - there are not much information about constrefs in Lazarus, several posts, the largest part of them is yours, Martin :) so you're probably one of the few who really understand it :) If constref is what you said , some "quick" fix for those who's scary of the current const behavior could be iintroducing a setting in fpc that forces all const to be constrefs. Max _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel