Am 07.04.2016 13:49 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-04-07 12:25, Martok wrote: > > If Move+FillChar would use out instead of var (as they should - they don't read > > the dest value, that's the whole point), that would be fixed once and for all. > > But I remember having this discussion before and apparently it was like this for > > some compatibility reason... > > I was about to mention that. This was discussed before, and there was a > reason (which eludes me now) why FillChar() will not be changed. And > that is also when I came up with the FillMem() solution. >
"out" and "var" behave different in rather subtle points and thus code that would currently work with FillChar would no longer work then or have subtle errors. > If FPC starts nagging about uninitialised pointer parameters (as in the > usage by FillMem(...) ), then I am afraid there is *no solution* to get > rid of that compiler hint for FPC 2.6.4. There is no warning/hint/whatever because a parameter is always assumed to be initialized (except it's am "out" one). > I haven't looked at what FPC 3.0's Default() function does yet, but > maybe FPC could implement a FillMem() exactly like FillChar() but with > an out parameter instead. So then FillChar() is there for whatever > backward compatibility, and FillMem() could be used going forward to get > rid of that compiler hint. Then again, I probably made this suggestion > in our previous discussions on this topic. ;-) Default() essentially creates a variable of the given type and sets it to zero (there are optimizations for simple types). Regards, Sven
-- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus