[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