0

Developing a window-32 bit application by using DelphiXE-7. I’ve following piece of code-

Procedure TMainForm.Button1Click(Sender: TObject);
Var
  iNum: Integer;
  bExit: Boolean;
Begin
  ShowMessage(IntToStr(iNum));
  repeat
    Inc(iNum);
    bExit := True;
  until Exit;
End;

I know that not initializing iNum before using it may cause this problem, but then it should also come at debugging time.

But when I’m debugging or running compiled exe MessageBox is showing as “0” which seems correct, but when we are installing build and running the same procedure then MessageBox is showing some garbage value instead of zero. Something like “1632824”.

Only difference between compiling and Build generation is that later one is not creating dcu.

Please Advise Accordingly.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
cvsingh
  • 106
  • 2
  • 13
  • See [Are delphi variables initialized with a value by default?](http://stackoverflow.com/q/132725/576719). – LU RD Feb 19 '16 at 07:15
  • http://docwiki.embarcadero.com/RADStudio/Seattle/en/Variables – splash Feb 19 '16 at 07:54
  • *Please Advise Accordingly*. Certainly. Initialize the variable properly, and the discrepancy between debug and non-debug will not exist, and the problem is solved once and for all. The easiest thing to do while you figure out which variables need initialization and which don't is just to initialize everything, and turn on compiler hints and warnings. The compiler will tell you when you've done an unnecessary initialization. (The same hints and warnings would have told you that you were using an uninitialized variable in your first line of code here.) – Ken White Feb 19 '16 at 13:34
  • @KenWhite - got it. Thanks. – cvsingh Feb 22 '16 at 05:22
  • Related to initialization: Delphi initializes boolean fields in a record improperly. More exactly, the field is initialized to 0 instead of true/false. So you can used Boolean(MyRecord.BoolField) to convert the field to true boolean } – Gabriel Mar 02 '16 at 21:29

1 Answers1

3

Global variables are in the application data segment, they are initialized with zeros when the program starts.

Class fields are initialized with zeros when objects are created (they might be filled later in constructors, Loaded(), etc).

Variables

Memory for local variables, like your iNum, is allocated dynamically in the program stack just during the function call, and local variable values are random and unpredictable when uninitialized. That is why initialization is a necessary step.

The exception to this rule is compiler-managed types - strings, interfaces, variants, dynamic arrays, etc - they are initialized with empty values.

Initializing Strings

MBo
  • 77,366
  • 5
  • 53
  • 86
  • 2
    All reference counted local variables (ie dynamic arrays too) are initialized (to nil) otherwise reference counting wouldn't work. – ain Feb 19 '16 at 06:49
  • 1
    Reference counted local variables are always initialised to a valid value, but that valid value need not be `nil`. Sometimes, the initial value of a function's `Result` comes from a prior invocation of the function. –  Feb 19 '16 at 07:00
  • it is understandable. What is happening at debug time. debug time iNum showing as assigned by zero. why it is showing garbage value when I'm installing via setup and running it? is there any problem with IDE or I'm getting wrong? – cvsingh Feb 19 '16 at 09:06
  • @Chand Your local variable is not initialized. It's initial value is undefined. Why are you expecting anything other than that? – David Heffernan Feb 19 '16 at 09:19
  • 1
    I see 124881 in my debug. Logic is simple - stack contains arbitrary data, significant part of these data probably are zeros, but you must not rely on lucky destiny. – MBo Feb 19 '16 at 09:19
  • @Chandraveer: I don't understand the issue. Initialize the variable properly, and the discrepancy between debug and release doesn't exist. – Ken White Feb 19 '16 at 13:33