Variable initialization by compiler - clarification needed

D4 Help claims that *global* variables are automatically initialized to 0, whereas *local* variables contain random data until a value is assigned to them.

For *global* variables I presume this means...

integers initialized to 0
booleans initialized to false
strings  initialised to ''
pointers / object refs initialized to nil
Is this correct?

Also, I assume that private/public member fields of a class are considered *global* variables in this context and are therefore also intialized to 0.  Is this also correct?

Do *local* variables then refer only to variables declared within a procedure or function, whether it be a unit function or class member function.

Do any compiler or linker settings affect how variables are initialized (e.g. optimisation)?

Clarification please.

Thanks

Andrew

andrewjacksonAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

TheNeilCommented:
To be safe, initialise everything yourself and don't trust the compiler one bit

The Neil
0
andrewjacksonAuthor Commented:
Yes, fair point, that is what I normally do.

However, I've trying to track down a bug which is very difficult to replicate.  I've found a private boolean variable in one of my classes which (by mistake) I've not initialised and which I suspect just might be the cause of the bug.  

It should be initialised to FALSE but if I manually initialise it to TRUE the bug occurs.  I want to establish if the compiler might every let that happen. However, all the testing I've done shows the compiler always initialising it to FALSE.  If that is the case then I will have to rule out this variable as the cause of my bug :(

Thanks anyway,

Regards

Andrew
0
JoeBoothCommented:
Add an assertion around the code where you expect the variable to be FALSE.  This way, the assertion will get triggered if the compiler does something funny, plus you'll be documenting the potential bug for other programmers (and yourself a year down the road)
0
Cloud Class® Course: C++ 11 Fundamentals

This course will introduce you to C++ 11 and teach you about syntax fundamentals.

andrewjacksonAuthor Commented:
Yes, I've tried that as part of my latest debugging effort but haven't been able to replicate the bug or trigger the assertion yet :( (The bug appears VERY occasionaly)

Also, the code forms part of a DCOM server. I can't really leave assertions in production or system testing code since an assertion or other message dialog popped-up by the server locks remote clients.

I just need clarifacation on what the compiler will or will not do with this variable when the object is instantiated so I can establish if its the cause of the bug.

Thanks anyway for you help

Andrew
0
MadshiCommented:
>> For *global* variables I presume this means...
>> integers initialized to 0
>> booleans initialized to false
>> strings  initialised to ''
>> pointers / object refs initialized to nil
>> Is this correct?

Exactly. BUT: They are initialized AFTER the initialization part of the unit was executed. So your code between "initialization ... end" must not rely on this.

>> Also, I assume that private/public member fields of a class are considered *global* variables in this context and are therefore also intialized to 0.  Is this also correct?

Yes.

>> Do *local* variables then refer only to variables declared within a procedure or function, whether it be a unit function or class member function.

Yes.

>> Do any compiler or linker settings affect how variables are initialized (e.g. optimisation)?

Optimization definetely not. I don't know, perhaps there's a hidden setting somewhere - but I don't know one.

Regards, Madshi.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
MadshiCommented:
P.S:

strings, wide strings, interface variables (D3 or higher) and dynamic arrays (D4 or higher) are ALWAYS initialized to 0 (or nil or '') - even in such a complicated type:

procedure test;
type TComplicated = array of record
    str: string;
    anotherRecord: array of record
      str2: string;
      dynArr: array of array of string;
      int: integer;
    end;
  end;
var compl : TComplicated;
begin


Now you can rely on that all dynamic parts of this record are initialized to 0 (otherwise you would get exceptions when using them). The only part of the record that is in this example NOT initialized is "compl.anotherRecord.int".

Regards, Madshi.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Delphi

From novice to tech pro — start learning today.