I still do not fully understand. On Thu, Nov 19, 2009 at 19:20, Martin <laza...@mfriebe.de> wrote:
> Jonas Maebe wrote: [skipped example] > Well in this case, the code is actually positively affected by the "out" > param (because it avoids the mem leak) Jonas, can you confirm that your example is incorrect one, and Martin's example below is actually what you meant? > But if you ever handled ref-counted data by hand..... > > type TStringArray = Array of string; > > procedure InsertOne(a: TStringArray); > var l : integer; > begin > l := length(a) > SetLength(a, l + 1) > Move(a[0], a[1], l*SizeOf(String)); > // now a[0] and a[1] point to the same string > // but the string has still a ref-count of 1 > // so assigning a[0] := nil => would release the memory used by a[1] > FillChar(a[0], SizeOf(String), 0); > end; > > the above works, because Filchar has a var param. otherwise it would > finalize the string, and a[1] would point to released memory.... Ugh, now this is what I consider to be very ugly. I did actually wrote exactly this kind of code for Delphi, but it never even occurred to me to rely on that undocumented distinction between out and var parameters. I wrote something like Integer(a[0]) := 0; instead. So I'd say that this the kind of broken code not worth supporting. -- Alexander S. Klenin _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
