[Lazarus] PDF generator, try 2
Sven Barth
pascaldragon at googlemail.com
Thu Apr 7 14:36:49 CEST 2016
Am 07.04.2016 13:49 schrieb "Graeme Geldenhuys" <
mailinglists at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160407/d23a829f/attachment-0003.html>
More information about the Lazarus
mailing list