[fpc-devel] Need patch for bugs : 0011503 / 0009472

[Boian Mitov]

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" <michael at freepascal.org>
To: "FPC developers' list" <fpc-devel at 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 at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel