In a lot of common cases, handling memory for local variables with a try ... finally can be easily avoided, as soon as you care about the scope of the variable.
In a lot of common cases, handling memory for local variables with a try ... finally can be easily avoided, as soon as you care about the scope of the variable.
We introduced some kind of automatic memory management to ease business code writing in our Open Source mORMot framework.
Not perfect, of course, but definitively some syntaxic sugar to be used on purpose, as a type saver.
http://blog.synopse.info/post/2014/11/14/Automatic-TSQLRecord-memory-handling
We introduced some kind of automatic memory management to ease business code writing in our Open Source mORMot framework.
Not perfect, of course, but definitively some syntaxic sugar to be used on purpose, as a type saver.
http://blog.synopse.info/post/2014/11/14/Automatic-TSQLRecord-memory-handling
RalfS reported on our forum - see http://synopse.info/forum/viewtopic.php?pid=13596#p13596 - that our trick won't work with FPC, unless you explicitly define a local variable for the IAutoFree interface.
ReplyDeleteSee http://bugs.freepascal.org/view.php?id=26602
I've updated the doc to reflect this FPC expectation.
That's still a try/finally block; it's just making the compiler invisibly insert it behind the scenes.
ReplyDeleteThat FPC issue is another perfect example of the FPC folks sometimes being stubborn and ignorant as f... They haven't heard of RAII it seems. Since variables in pascal don't have a smaller scope than a routine it's stupid to finalize the result earlier than at the end of the routine even if its an implicit compiler generated one.
ReplyDeleteThanks for sharing this interface trick: it deserves to be known better among the Delphi public.
ReplyDeleteI wrote two similar posts a while ago that caused some interesting comment back then (and a few interesting videos by Alister Christie).
Thanks to the comments, I still use the technique, but with more caution.
http://wiert.me/2014/08/06/delphi-using-iinterface-to-restore-cursor-at-end-of-mehod-prelude-to-a-memento-that-executes-any-code-at-end-of-method/
http://wiert.me/2014/08/07/delphi-a-memento-that-executes-any-code-at-end-of-method/
Jeroen Wiert Pluimers Yes, I tried to document those classes and method to explicitly warn about the exact use of those structures: they are just to be used on local variables, to avoid a try..finally.
ReplyDeleteStefan Glienke I gotta say I agree with the FPC folks on this. It's a neat trick (one I've used myself) but it does depend on an undocumented implementation detail. There really isn't a reason to expect the return value of a function to persist beyond the function call if it isn't assigned to a variable.
ReplyDeleteKenneth Cochran it is not undocumented but hard to find (see my blog posts), and anonymous methods depend on it (for proper cleanup). So yes: you can expect it to work in Delphi.
ReplyDeleteJeroen Wiert Pluimers I read your blog posts twice and followed every link but I honestly have to say none pointed to documentation. You mentioned a post by Danny Thorpe on SO as "documentation" but I would not count it, because he just was guessing from memory.
ReplyDeleteKenneth Cochran This behavior has been used in various ways over the years. And we all know this is not only the case for interfaces but all managed types that might get returned by a function without assigning them explicitly. Even the order of finalization is deterministic iirc (in the order of creation). So even if it is not documented the explicit early finalization does not make much sense.
I asked Marco Cantù if Allen Bauer has more info so we are not left in the dark about this any longer. :)