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

[Florian Klaempfl]

Boian Mitov schrieb:
> 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:

Unfortunatly, I can quote only from the german delphi help: "Wenn Sie 
die Referenzzählung nutzen wollen, dürfen Sie das Objekt nur als 
Schnittstellenreferenz verwalten." It says, if you want to use the 
reference counting, you might store the class only as interface 
reference. I guess FLock is no interface?

Further, how is in delphi ensured that WriteLock:=Nil; doesn't release 
FLock?

> 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();, 

The .Free is probably the error here. If FLock inherits from 
TInterfacedObject, calling release is the way to go.

> 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 
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>