Am 30.06.2018 um 12:02 schrieb Willibald Krenn:
Gesendet: Samstag, 30. Juni 2018 um 10:54 Uhr
Von: "Michael Van Canneyt" <mich...@freepascal.org>
Am 30.06.2018 um 08:47 schrieb Sven Barth via fpc-devel:
The variables we're talking about here *are* initialized.
Bit lost here. Maybe A and B are setup, but not result. And the apparent re-use of tmp vars also
seems wrong. In the first call you get a "setup" var, in the second call an
"initialized" one with previous values. But the latter is not commonly referred to as
initialization, as initialization means usually setting to a sensible default value, which always
is the same.
Maybe the term initialized is wrong and confusing. They are not initialized
in the sense of having defined values as
global variables have. Non-global managed types should not be considered as
being initialized (never!, like any other
type), this is also why the compiler warns (!) about this. They can be
considered as being "setup" by the compiler.
So what does setup do - allocate memory and set refcount accordingly?
No. Consistent in the sense that ref. counting works and causes no leaks.
If result was being setup properly that might also help.
It is setup, but not initialized.
They contain valid values and none of the internal RTL
routines will crash when used with them. Everyone however expects result
variables of those to be initialized to Nil and
that is simply *not* a guaranteed given.
I'd say if everyone expects that then there is a point in that the current
behaviour is surprising and not intuitive. I mean, the compiler is for people,
right? ;)
Also records only initialize their managed fields. All others are left as
garbage.
I'm only talking about managed types.
Managed fields of records are "setup" ;)
I will add a section about this in the documentation, seeing that people
often confuse the 2 concepts.
In an ideal world, either the language would not let you write code that has
random behavior or the compiler would enforce this.
Compile with trunk and -Sew and you get this behavior.
Out of curiosity I did a couple of more tests and it seems FPC is pretty
inconsistent in handling all this. See below.
Pretty useless code fragment.
1) This is fpc-devel and not lazarus-same-random-code, it does not compile
without lazarus and even not with it.
2) If I guess the missing parts right, the example simply points out a bug of the setlength handling which is handled
internally but this is fixed now.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
