[fpc-pascal] SetLength warnings - request
jonas at freepascal.org
Mon Dec 31 10:04:36 CET 2018
On 2018-12-31 02:54, Martok wrote:
>> There is a hint for such parameters even though the compiler knows
>> always contain a valid value, because valid in the sense of "won't
>> the program" is not the same as "this is what the programmer
> Are you baiting me, or was that accidental? ;-)
I'm 100% serious about the above. Code should be explicit, not implicit.
It's up to the compiler to remove unnecessary code based on what it
knows is implicitly guaranteed. The programmer should only have to focus
on the algorithms and on making their code as explicit/clear as
possible. Removing initialisations based on the type of variables (which
then may have to be re-added in case the type or usage changes) does not
help with that.
In that sense, the optimisation capabilities of a compiler are quite
important for the quality of the code that people write, because a
better optimiser means that (some) people are less inclined to mangle
their code and "tune" it to implementation details in order to coax the
compiler into generating the code they want to see.
>> 1) Dynamic arrays are initialised with nil, but that is an
>> implementation detail
> Is it, though? Global variables and instance fields are zero-filled,
> variables as if the local variable block was a record passed to
> (so, recursively zeroing managed fields). Although it is never spelled
> out, the
> Delphi manual heavily implies this.
> I would guess most if not all pascal programmers wrote code that relies
> on that
> at some point.
Yes, and that indeed would make it very hard to change any of that
without breaking any code. The fact that people rely on implementation
details does not make them any less of an implementation detail. In this
context, "detail" does not mean "less significant fact or item" but
"individual fact or item".
In general, the Turbo/Borland/Free Pascal community is very bad in terms
of relying on implementation details. This is normal if you only have
one dominant compiler. It's the same for individual companies (=
mini-communities) that only use e.g. Visual C++ or GCC.
> @MvC: I'll come up with some examples and add it to the Portability
> page, since
> the different result variable initialization rules already are a bit
> of an issue.
Since such code will also give wrong results in Delphi under certain
circumstances (which most Delphi programmers probably don't know,
because usually string result variables _are_ indeed nil there), this is
a perfect illustration of my first point. Especially since unless you
are clairvoyant, it is impossible to know that your function will never
be used in the future in a way that will cause the result to be
non-empty from the start.
More information about the fpc-pascal