Bogus W1036 ?
Bogus W1036 ?
Documentation: http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Variables_(Delphi)
"If you do not explicitly initialize a global variable, the compiler initializes it to 0."
Code:
{$APPTYPE CONSOLE}
var
i: Integer;
begin
Writeln(i);
end.
[DCC Warning] Project1.dpr(6): W1036 Variable 'i' might not have been initialized
Documentation: http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Variables_(Delphi)
"If you do not explicitly initialize a global variable, the compiler initializes it to 0."
Code:
{$APPTYPE CONSOLE}
var
i: Integer;
begin
Writeln(i);
end.
[DCC Warning] Project1.dpr(6): W1036 Variable 'i' might not have been initialized
Only in a .dpr file, right? Not in a unit file I think.
ReplyDeleteYes, only if the variable is in the dpr as well. And many times it disappears when the variable is used in some ways.
ReplyDeleteIt is a bit complicated.
ReplyDeleteGlobal variables are automatically initialized - with the exception of the main program’s begin...end block where some variables may be treated as local ones.
stackoverflow.com - Which variables are initialized when in Delphi?
Yes! but apart of the Application Variable and maybe the instance of the main controller, for what do you need a global variable?
ReplyDeleteSounds like a poor design. Don't true?
(It's a sarcastic think, And not) (jejeje)
Juan C. Cilleruelo It's not about its usefulness but about the correctness of the compiler and/or the documentation.
ReplyDeleteDalija Prasnikar In Stefan's example it's a global. And it is zero initialized.
ReplyDeleteFor interest, this reminds me of a discussion on FPC list recently (not the same issue exactly but similar, you might want to bring some popcorn ;) ): fpc-devel.freepascal.narkive.com - Wrong docs: not initialized global variables
ReplyDeleteDavid Heffernan I wanted to point out that not all globals are equal.
ReplyDeleteAlso there is a question of global visibility. Global variables declared in dpr have limited accessibility, just like global variables declared in implementation section of a unit. You will get the same kind of warning for them, while you will not have the warning for globals in the interface section.
But I am probably digressing from original question.... I am kind of more interested why is compiler behaving the way it does, and what is its inner logic... or whether there are some deeper reasons for this or it is just plain deficiency in compiler.
Back to the question...
First, I would say warning is bogus and documentation is correct.
Next, I would also say, don't ever count on automatic initialization of non-managed types unless they are members of a class.
Well, the warning says “might”... ;)
ReplyDeleteAttila Kovacs No. It's not on the heap. It's a global.
ReplyDeleteAccording to the language spec these are global variables in scope (seen by "all" code) and implementation (initialized to zero).
ReplyDeleteIt seems like the warning-generating part of the compiler treats them as local variables (thinking they are not initialized). It is a bug, albeit a minor one IMO.
There is no semantic reason they have to be global, as no other code can see them. You could have moved the code to a procedure and made them local variables, and it would have the same semantics.