On 2018-12-31 02:54, Martok wrote:
There is a hint for such parameters even though the compiler knows
they
always contain a valid value, because valid in the sense of "won't
crash
the program" is not the same as "this is what the programmer
intended".
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,
local
variables as if the local variable block was a record passed to
Initialize()
(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.
Jonas
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
