On Fri, 1 Apr 2011, Bart wrote:
On 3/31/11, José Mejuto <joshy...@gmail.com> wrote:
B> This however means that the programmer has to protect TIniFile.Free
B> with a Try..Except block, which is also rather unusual.
It's unusual, but there is an error, or the class does not perform the
save in the free procedure and uses a "flush" (forced) or the class
must raise an exception as the expected job has not been performed.
The job of the destructor, however, is to clean up the object and return memory.
This should never fail IMHO.
One could even argue that the whole call to UpdateFile in the
destructor simply should not be there.
If the user (programmer) takes the risk of caching the write updates,
then it is the programmers responsability to make sure the cached
values are written at some point.
The problem is Delphi compatibility.
If you use TMemIniFile, then you know that you must call UpdateFile.
When using TIniFile, however, Delphi uses the windows API. This makes sure that
each write is automatically committed to Disk. (well, we hope so)
Since this is not portable, the FPC TIniFile in fact descends from TMemIniFile.
It should be compatible to Delphi's TiniFile, i.e. the programmer should not
worry about 'updating the file', this should be done automatically.
There are 2 options then:
1. Do an UpdateFile after each write.
This used to be the default behaviour, but is VERY slow because each write
statement
causes the entire file to be written to disk.
2. Cache the updates, and make sure they are written when the instance is
destroyed.
This is the current behaviour. It works fast, but the corner case you
encountered
(an error when updating the file in the destructor) is now an issue.
Going back to 1 is not an option.
For case 2, I am inclined to say that the destructor must always succeed.
Errors in destructors are very ugly to trap.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
