Hint message "Local variable xx does not seem to be initialized" problem

[dbannon]

Just to be really, really clear here. There are two (maybe more) messages about uninitialized vars.

Code: Pascal  [Select][+][-]

1. procedure SomeMethod();
2. var
3.   a: SysUtils.TStringArray;
4.   b : string;
5. begin
6.   if b = '' then exit;   // WARNING (5089) ....
7.   SetLength(a, 1);       // HINT (5091) ....  

         

They have different numbers and one is a warning, one a hint. Hints are generally nothing to worry about but I like to fix them if I can, warning should almost always be taken seriously.

• SetLength is a intrinsic, its much closer to the compiler and the language itself that the libraries for example. That means the devs are reluctant to change it.
• tt, I mentioned adding a := nil between SetLength() calls to demonstrate that it did not lead to a memory leak, not to avoid the problem. But its not unreasonable ...
• Nicole, an array is a local (managed) variable, its not created with new or create, the compiler will free up any memory used when it goes out of scope. The compiler is your friend.
• Command line compiles using fpc do not show hints by default, Lazarus does. So, in the code snippit above, the 5091 is not shown, the 5089 one is.
• This behavior is in all available versions of FPC, installing different versions will not change it. Its regarded as harmless and perhaps a good talking point over a beer. Personally, I think its confusing.
• Right click in the editor window gutter, on the warning or hint icon to get some quick fixes

Looking back through my own code, I realise I have just set a:=nil to avoid the hint, while I should really just have turned it off.

Davo

[Nicole]

Code: Text  [Select][+][-]

1. Nicole, an array is a local (managed) variable, its not created with new or create, the compiler will free up any memory used when it goes out of scope. The compiler is your friend.

This sentence seems extremely important to me, although I do not understand it in full.

I work a lot with dynamic arrays.
At the moment I administrate them in blocks because SetLenth(myArray(Langth(myArray)+1) or so had large performance penalties. I am not happy with this complex block creation. But it is the best I found.

On destroy I learned to destroy them one level by the next one nested. So I removed the content of the array basically, then the array which had hold it, then the above one...

After I checked this I found, that it is slllowwwww. The performance grew better, if I left the basic figures alone and just wrote about the 'main' array (which holds all others):

SetLength(myArray,0);

I cannot remember, what I tried to clean up. This went from Delphi 7 to XE3 and so on. I cannot remember what all was "not allowed" and "pointer to Nil" keeping my busy if I cleaned up an already empty array.

The short question after the long text (I hope, it is short!):
How to clean up dynamic arrays for best style?

[dbannon]

All Arrays, including dynamic are cleaned up (by compiler code) when they go out of scope. So, an array declared in a function goes away as soon as that function finishes.

You might want to zero out a big global array before it happens automatically if you know you have finished with it and its using a lot of memory but you do not have to.  Do some tests, declare an array, put something in it and leave it there, heaptrc will not report a memory leak.

Now, performance ? Adding one element at a time is bad for performance, arrays, strings, string list etc. So, perhaps your complex code is doing a good job !

I have not used Delphi since Delphi Two and I am not really a big array user so better advice must surely be available.

Davo

 

[Nicole]

Thank you for the explanation!
btw:
Is there a tool for memory leaks? Under Delphi it was fastMM or similar.

[Bart]

Build with HeapTrace enabled (it's in compiler settings under Debugging if you use Lazarus, otherwise add "-gh" to the compiler swithces at the commandline (without the quotes of course)).

Bart

[PascalDragon]

I work a lot with dynamic arrays.
At the moment I administrate them in blocks because SetLenth(myArray(Langth(myArray)+1) or so had large performance penalties. I am not happy with this complex block creation. But it is the best I found.

That is indeed the recommended way when working with arrays: either you know the final size beforehand or you do some growth by the power of two and then shrink it back to the final size.
Alternatively it might be better to use a list class which already does that inside (e.g. TList).

On destroy I learned to destroy them one level by the next one nested. So I removed the content of the array basically, then the array which had hold it, then the above one...

You don't need to deal with releasing the array itself. However you might need to handle the contents: if you allocated the contents yourself (e.g. some pointer or class instances) then you need to release them yourself as well. If the elements are of a  managed type (e.g. AnsiString or some descendant of IInterface) then you don't need to do anything same if you have a simple type as elements (e.g. sets, integers, etc.).

[marcov]

(afaik most lists nowadays taper of exponential growth when the array becomes really bigs (hundreds of MBs)

[Thaddy]

@PascalDragon:
Not a power of two but the golden ratio is way more efficient. ~1.618

[Чебурашка]

Hello,
I now realize that the best way to build the software is outside Lazarus. This means:

1. during normal day developement work under lazarus, build and debug there
2. when the development is over, build outside lazarus wih the "default" compiler setting, in order to make sure the code compiles and generates warnings/hints/notes according to fpc developers default settings.

What is the bast way to do it?

LazBuild i guess is not, because basically uses same configuration used by Lazarus.

So what is best way to to this?

Thanks

[Thaddy]

Code: Pascal  [Select][+][-]

1. {$mode objfpc}
2. uses sysutils;
3. var
4.   a: TStringArray =();
5.   b : string ='';
6. begin
7.   if b = '' then exit;   // NO WARNING (5089) ....
8.   SetLength(a, 1);       // NO HINT (5091) ....  
9. end.

[MarkMLl]

Code: Pascal  [Select][+][-]

1.   a: TStringArray =();
2.   b : string ='';
3.  

But I thought that was supposed to be implicit for managed types, or is there a mode dependency there?

Doesn't stop me from doing it explicitly mind...

MarkMLl

[dbannon]

TT

2. when the development is over, build outside lazarus wih the "default" compiler setting, in order to make sure the code compiles and generates warnings/hints/notes according to fpc developers default settings.

Within Lazarus, click Project->ProjectOptions->ShowOptions that will show you a fpc command line.

However, I am not sure I agree with the premise here. But I do develop in Lazarus, compile, run test, debug (etc) but when I do a Release, its all built in a VM that is dedicated to just that task and I use a bash script (see my project) to build (and incidentally, package) at each release.

@Thaddy - would it be fair to say that your example does not generate output about non-initialization because you are initializing both those variables ?

Davo

[Thaddy]

But I thought that was supposed to be implicit for managed types, or is there a mode dependency there?

It depends on two things:
- heap or stack, heap is clean, stack is not (with the default MM)

[MarkMLl]

It depends on two things:
- heap or stack, heap is clean, stack is not (with the default MM)

So those two surely should have been on the heap?

However I suspect your "with the default MM" is crucial there: the compiler doesn't know when it's processing the source.

MarkMLl

[alpine]

But I thought that was supposed to be implicit for managed types, or is there a mode dependency there?

It depends on two things:
- heap or stack, heap is clean, stack is not (with the default MM)

It doesn't. That's why we call them "managed".

@Mark
I suspect the messages are because they're expected to be initialized explicitly.