How objects are initialized in delphi XE vs XE4

Question

I have a class

type
  TLoadOption = class
  private
    FAutoSearch: Boolean;
  public
    property AutoSearch: Boolean read FAutoSearch write FAutoSearch;
  end;

In one of the functions i am creating the object of the class in stack

procedure MyView.InitializeForm(const aMsg: MyMsg);
//---------------------------------------------------------------------------
var
  Options: TLoadOption;
begin

  if aMsg.OptionalObject <> nil then
   Options := aMsg.OptionalObject as TLoadOption;

  if Assigned(Options) and Options.AutoSearch then
    DoRefresh;
end;

I am not passing anything in aMsg so ideally Options is not set.

In Delphi XE by default Options is set as nil and so this DoRefresh is not called but when i execute the same code in Delpi XE4 the options is initialized with some random value and AutoSearch becomes true always and it results in calling this DoRefresh function which is undesired.

I am wondering if there are any compiler options that set default values to uninitialized variable. My only solution as of now is like this

 procedure MyView.InitializeForm(const aMsg: MyMsg);
    //---------------------------------------------------------------------------
    var
      Options: TLoadOption;
    begin
      Options := nil;

      if aMsg.OptionalObject <> nil then
       Options := aMsg.OptionalObject as TLoadOption;

      if Assigned(Options) and Options.AutoSearch then
        DoRefresh;
    end;

is this a correct way?

What is MyMsg? This is a class, record or what? You say about default value, but this param have no default value in your case. How you assign default value? — Darthman, Mar 07 '14 at 10:26
Didn't the compiler warn you about that code? It should have told you that `Options` was uninitialized. Never ignore a compiler warning. — Rob Kennedy, Mar 07 '14 at 13:16
You accepted the answer that gave the best solution to your problem, but also did not actually answer the question you asked. You asked about initialization of a local variable. — David Heffernan, Mar 10 '14 at 07:04

score 11 · Answer 1 · edited May 23 '17 at 12:33

A local class is not initialized. You need to set it to nil before testing its assignment.

See Are delphi variables initialized with a value by default?.

Only local reference-counted variables are initialized (example: String,dynamic arrays,interface,variants).

If you are targeting mobile platforms, where ARC (automatic reference counting) is introduced, classes are reference counted though. See Automatic Reference Counting in Delphi Mobile Compilers.

Stefan Glienke · Accepted Answer · 2014-03-07T13:09:06.280

As the other answers already said the local variable is not initialized. However what I like to add here is that as is nil safe. That means you don't need to check if aMsg.OptionalObject is assigned. You can just write:

var
  Options: TLoadOption;
begin
  Options := aMsg.OptionalObject as TLoadOption;

  if Assigned(Options) and Options.AutoSearch then
    DoRefresh;
end;

Keep in mind that it will throw an exception if OptionalObject does not inherit from TLoadOption. The code looks as that is always the case. So if you are sure about that you can use a hardcast:

begin
  if Assigned(aMsg.OptionalObject) and TLoadOption(aMsg.OptionalObject).AutoSearch then
    DoRefresh;
end;

J... · Answer 3 · 2014-03-07T10:40:10.843

No. Assuming that TLoadOption is an object (unmanaged reference type) you have to initialize local variables yourself. There is no option to have them initialized for you. Local variables for reference types (except for managed types like strings, etc) that are uninitialized will always contain whatever garbage data was in that location on the stack. This makes use of Assigned impossible.

You might just simplify your code a bit, but this is about as short as it can get.

var
  Options: TLoadOption;
begin
  if aMsg.OptionalObject <> nil then begin
    Options := aMsg.OptionalObject as TLoadOption;
    if Options.AutoSearch then DoRefresh;
  end;
end;

score 3 · Answer 4 · answered Mar 07 '14 at 10:36

3

Options is a local variable, of a non-managed type. Which means that it is not initialized. It can have any value until you initialize it. If the variable sometimes happens to have the value nil without you having initialized it, then that's just unlucky for you.

You must initialize local variables before attempting to read them.

answered Mar 07 '14 at 10:36

David Heffernan

601,492
42
1,072
1,490

Thanks for your answer but i am curious on How it always work fine in XE? – Jeeva Mar 07 '14 at 11:37
1

@Jeeva He answered that - you were just lucky. The most likely explanation is that the calling function (or some previous function) semi-reliably left something higher up on the stack (where your variable ended up) that made the code work - and now that has somehow changed. – J... Mar 07 '14 at 11:54
1

@Jeeva An uninitialized value can have any value. Including `nil`. – David Heffernan Mar 07 '14 at 12:05
@Jeeva Are you sure you are building with the exact same options? It might already change if you change some compiler options (optimization, stack frames, etc). – Stefan Glienke Mar 07 '14 at 13:12
@DavidHeffernan Fair point. Let us be neutral in making value judgements and perhaps say that it worked *by chance*... making what we will of that outcome ;D – J... Mar 07 '14 at 13:26
@J... Although I'm joking a little here, the joke highlights a more serious point. In my opinion if code works just by the chance content of an uninitialized local, then that is unlucky. That is a bad outcome for you. A good outcome is that the code fails immediately. Then you can fix the bug. Latent bugs that don't manifest are worse than bugs that do manifest. That's why I believe that the asker has been unlucky. – David Heffernan Mar 07 '14 at 13:29
@DavidHeffernan Your meaning was clear. I was just injecting some levity and wordplay. Lucky meaning achieving the expected behaviour against strong odds...it doesn't necessarily have to imply 'fortunate'. – J... Mar 07 '14 at 13:50

score 1 · Answer 5 · answered Mar 07 '14 at 12:19

1

You don't need local var at all.

procedure MyView.InitializeForm(const aMsg: MyMsg);
begin
  if Assigned(aMsg.OptionalObject)
    and (aMsg.OptionalObject is TLoadOption)
    and (aMsg.OptionalObject as TLoadOption).AutoSearch
  then
    DoRefresh;
end;

answered Mar 07 '14 at 12:19

kot-da-vinci

1,152
16
30

1. You don't need local var. 2. You don't need to initialize it. 3. If OptionalObject does not inherit from TLoadOption nothing will break. 4. As for me this code is logical. – kot-da-vinci Mar 10 '14 at 06:53
The local var is good. It makes the code better. It allows you to avoid repeating yourself over and over as you do. – David Heffernan Mar 10 '14 at 07:02

How objects are initialized in delphi XE vs XE4

5 Answers5