Here is a code sniped that sows just one example of the problem:
This is a very simple example of how important the order really is:
We have even more crucial problems related with this. This is just a simple
one:
destructor TALBasicAudioOut.Destroy();
var
WriteLock : IOWLockSection;
begin
WriteLock := FLock.StopLock();
FInputPin.Free();
FEnablePin.Free();
FMasterPumping.Free();
WriteLock := NIL;
FLock.Free();
inherited;
end;
You can see that the WriteLock MUST be released before the FLock.Free();,
otherwise you will have access violation, and this is a destructor, so the
options are limited.
With best regards,
Boian Mitov
--------------------------------------------------------------------
Mitov Software
http://www.mitov.com
--------------------------------------------------------------------
----- Original Message -----
From: "Michael Van Canneyt" <[EMAIL PROTECTED]>
To: "FPC developers' list" <fpc-devel@lists.freepascal.org>
Sent: Thursday, June 19, 2008 5:16 AM
Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
On Thu, 19 Jun 2008, Boian Mitov wrote:
Hi Michael,
Thank you! I will be looking into the code, and see if I can add the
functionality with some switch. We may redo the code, however it will
probably
take well over a year for fully rewriting it all, and it may not be
necessarily a smart thing. Delphi unlike C++ does not have any form of
function or block enclosement, and the interfaces are the closest thing
to
functional enclosement we have, aside from the error prone try/finally
pair.
If we lose it, we lose a major development tool :-( . It surely
downgrades the
Pascal language a notch. I hope however that sometime in the future we
will
finally have a real functional enclosement in Pascal, but who know ;-) .
I can see that you really want this feature, this is for sure.
However, nowhere you write WHY you need this feature;
The behaviour you seem to expect is wrong by definition.
As stated:
There are *no* leaks. The memory is freed at procedure exit;
This is just a little later than what you expect. (you expect it right
after the :=Nil;)
So WHY do you expect/need this behaviour ?
What architectural decision makes this necessary ?
I am asking this because I find it hard to believe that you would
write conciously code which really depends on this feature.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
