Board index » delphi » Questions on free'ing resources and killing compiler warnings

Questions on free'ing resources and killing compiler warnings

Hi All,

I'm just finishing up a small Delphi7 project I've been working with
for a while. Right now, I'm in the process of making it more robust
and resource friendly.

Q: I have a TForm.OnCreate event that create other classes. Where is
the best place to free those classes? In an OnClose? or an OnDestroy?
Delphi help says:

"Use OnDestroy to perform special processing when the form is
destroyed. Either implement this event or override the destructor of
the class, but not both. This event should destroy any objects created
in the OnCreate event."

...but my code doesn't seem to be executing in OnDestroy.

Q: I turned on the compiler warnings with Project->Options->Compiler
Messages and was astounded by the number of warnings. This one though
has me stumped:

  var
    FS: TFileStream;
    sNFOBuffer: String;
  begin
    [snip]
    FS.ReadBuffer(sNFOBuffer[1], FS.Size);
                  ^
[Warning] NFOUnit.pas(135): Unsafe code 'String index to var param'

I've tried every type cast I know to get this to compile with no
complaining. Any suggestions? Or am I just being paranoid.

Roger

 

Re:Questions on free'ing resources and killing compiler warnings


Quote
> ...but my code doesn't seem to be executing in OnDestroy.

OnDestroy is the correct place.
It should always execute as long as the event handler is hooked up.

Quote
> I've tried every type cast I know to get this to compile with no
> complaining. Any suggestions? Or am I just being paranoid.

As long as you are calling
    SetLength(sNFOBuffer, FS.size);
before the ReadBuffer call, this should be safe enough (I think).

This code will also do what you want without warnings:
    Str := TStringStream.Create('');
    Str.CopyFrom(FS, 0);
    sNFOBuffer := Str.DataString;

Or you could try the absolute directive:
  var
    FS: TFileStream;
    sNFOBuffer: String;
    buf: char absolute sNFOBuffer[1];
  begin
    [snip]

    SetLength(sNFOBuffer, FS.size);
    FS.ReadBuffer(buf, FS.Size);

Cheers,
Frank.

Re:Questions on free'ing resources and killing compiler warnings


Quote
Roger Helliwell wrote in message

<954bvu43k93rgi3g7iqnvmba3fkgjtk...@4ax.com>...

Quote
>Hi All,

>I'm just finishing up a small Delphi7 project I've been working with
>for a while. Right now, I'm in the process of making it more robust
>and resource friendly.

>Q: I have a TForm.OnCreate event that create other classes. Where is
>the best place to free those classes? In an OnClose? or an OnDestroy?

The complement of OnCreate: that would be OnDestroy.

Quote
>Delphi help says:
>"Use OnDestroy to perform special processing when the form is
>destroyed. Either implement this event or override the destructor of
>the class, but not both. This event should destroy any objects created
>in the OnCreate event."

>...but my code doesn't seem to be executing in OnDestroy.

Does it ever get called? To be exact, is the form ever
destroyed? How? How do you know?

Quote
>Q: I turned on the compiler warnings with Project->Options->Compiler
>Messages

No no no, that's all wrong. You don't turn that off. *Ever*.

Quote
>         and was astounded by the number of warnings. This one though
>has me stumped:

>  var
>    FS: TFileStream;
>    sNFOBuffer: String;
>  begin
>    [snip]
>    FS.ReadBuffer(sNFOBuffer[1], FS.Size);
>                  ^
>[Warning] NFOUnit.pas(135): Unsafe code 'String index to var param'

>I've tried every type cast I know to get this to compile with no
>complaining. Any suggestions? Or am I just being paranoid.

No, the compiler is being paranoid, and with good reason.
(The reason is you, of course. Ask Jerry. (ducks))

That parameter is not a string, it's really the address of
a buffer. Strings don't live at constant addresses, so the
buffer address may be rendered invalid at unpredictable
moments. As Murphy teaches, the only thing predictable about
it will be that you'll find out you made a mistake at the
worst time possible.

In practice, you set the string's length before _and_ after
the function call; the function does not store the buffer's
address for later usage; and things do work out. But the time
will come when you find out that one of those three rules was
broken, and it will be the worst possible time.

Groetjes,
Maarten Wiltink

Other Threads