Re: [fpc-pascal] destructor

[Nitorami]

As I understand this: It may sometimes well be necessary to write your own
destructor to clean up. But if you do this, don't call it foo; call it
destructor and override it: destructor destroy; override; 
In your own destructor method, don't forget to call inherited in the end.





--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/destructor-tp5727426p5727549.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] destructor

[Mattias Gaertner]

On Tue, 24 Jan 2017 15:33:30 +0100
Maciej Izak  wrote:

> 2017-01-24 12:48 GMT+01:00 Mattias Gaertner :
> 
> > fpc allows to declare a method with the destructor keyword, that is
> > not a real destructor, because it does not free the memory. For what is
> > this feature good for?
> >  
> 
> with trunk works as expected (Foo does call FreeInstance).

True.
Sorry, I mixed two destructors. Now I understand the Note: Class should have 
one destructor only.

Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] destructor

[Maciej Izak]

2017-01-24 12:48 GMT+01:00 Mattias Gaertner :

> fpc allows to declare a method with the destructor keyword, that is
> not a real destructor, because it does not free the memory. For what is
> this feature good for?
>

with trunk works as expected (Foo does call FreeInstance).

-- 
Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] destructor TDecompressionStream.Destroy question

[Michael Van Canneyt]

On Thu, 20 Sep 2007, David Mears wrote:

 from fpc/packages/fcl-base/src/inc/zstream.pp
 
 I'm not really sure why this is in the destructor for tdecompressionstream.
 
   if FZRec.avail_in  0 then
 Source.Seek(-FZRec.avail_in, soFromCurrent);

To reposition the source stream on the last actually read data.

 
 my tdecompressionstream  is fed by a tideadecryptstream - when
 tdecompressionstream is freed it causes that seek in the decrypt for
 some reason? , which isn't supported by the tdecryptionstream and it
 throws a EIDEAError - or is there a problem with the source stream? 

No, this is normal.

 
 generally I feel that exceptions are somehow uncivilized, so avoiding
 one so totally unnecessary  (in context, at least) would be appreciated.

I'll introduce a property in TDecompressionstream: 'SourceSeekable' or so
which can be used to control the behaviour.

Another solution is to implement a long-standing idea of mine: 

to introduce a property in TStream:
  StreamCapabilities : TStreamCapabilities;
with
  TStreamCapability = (scSeekForward,scSeekBackward,scRead,scWrite,scSize);
  TStreamCapabilities = set of TStreamCapability;

I think I'll go for the latter one.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] destructor TDecompressionStream.Destroy question

[David Mears]

Michael Van Canneyt wrote:
 On Thu, 20 Sep 2007, David Mears wrote:

   
 from fpc/packages/fcl-base/src/inc/zstream.pp

 I'm not really sure why this is in the destructor for tdecompressionstream.

   if FZRec.avail_in  0 then
 Source.Seek(-FZRec.i, soFromCurrent);
 

 To reposition the source stream on the last actually read data.

  
   
 my tdecompressionstream  is fed by a tideadecryptstream - when
 tdecompressionstream is freed it causes that seek in the decrypt for
 some reason? , which isn't supported by the tdecryptionstream and it
 throws a EIDEAError - or is there a problem with the source stream? 
 

 No, this is normal.

   
 generally I feel that exceptions are somehow uncivilized, so avoiding
 one so totally unnecessary  (in context, at least) would be appreciated.
 

 I'll introduce a property in TDecompressionstream: 'SourceSeekable' or so
 which can be used to control the behaviour.

 Another solution is to implement a long-standing idea of mine: 

 to introduce a property in TStream:
   StreamCapabilities : TStreamCapabilities;
 with
   TStreamCapability = (scSeekForward,scSeekBackward,scRead,scWrite,scSize);
   TStreamCapabilities = set of TStreamCapability;

 I think I'll go for the latter one.

 Michael.
 ___
 fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-pascal
   
I like the capabilities solution.  It has the feel of the pascal way to
do it.  There shouldn't be anything in the stream when free is called,
will research more what all is going on with that. 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal