<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-NZ link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I spotted that they fixed that a while ago – I remember having to fix the issue myself many years ago so was quite pleased to see that it was now taken care of in TInterfaceObject as a matter of course. For some reason I never noticed the omission of the same facility in the destructor. And yes, it’s a [potentially] big problem.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I need to think about this tho... setting a fake ref count during execution of the constructor is safe enough as you know precisely when construction is done and to restore the ref count back to zero.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Setting a fake ref count during destruction strikes me as more problematic and makes me nervous, but I can’t quite put my finger on why. It might be nothing. That doesn’t mean it can’t be fixed, only that the solution put in place for construction might not work for destruction and it wasn’t felt necessary to do any extra work for a more comprehensive solution.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Certainly in the case of my code where I fixed this I had specific “constructing” / “destructing” state markers (it wasn’t a general purpose interfacedobject class but a base class in a far richer framework that happened to also implement its own version of IUnknown) – I know I didn’t rely on side effects of a faked ref count.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> delphi-bounces@delphi.org.nz [mailto:delphi-bounces@delphi.org.nz] <b>On Behalf Of </b>Todd<br><b>Sent:</b> Wednesday, 24 November 2010 16:55<br><b>To:</b> NZ Borland Developers Group - Delphi List<br><b>Subject:</b> [DUG] How's this for inconsistent<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The Delphi developer who implemented TInterfacedObject obviously considered the case when an interface reference is grabbed during construction......<br><br><span style='font-size:10.0pt'>// Set an implicit refcount so that refcounting<br>// during construction won't destroy the object.<br>class function TInterfacedObject.NewInstance: TObject;<br>begin<br> Result := inherited NewInstance;<br> TInterfacedObject(Result).FRefCount := 1;<br>end;<br><br>procedure TInterfacedObject.AfterConstruction;<br>begin<br>// Release the constructor's implicit refcount<br> InterlockedDecrement(FRefCount);<br>end;</span><br><br>but didn't consider applying the same logic during destruction. So grabing an interface reference during destruction causes all hell to break loose, as the _Release method tries to free the object again and again recursively.<br><br><span style='font-size:10.0pt'>procedure TInterfacedObject.BeforeDestruction;<br>begin<br> if RefCount <> 0 then<br> Error(reInvalidPtr);<br>end;</span><br><br><span style='font-size:10.0pt'>function TInterfacedObject._Release: Integer;<br>begin<br> Result := InterlockedDecrement(FRefCount);<br> if Result = 0 then<br> Destroy;<br>end;</span><br><br>Todd.<o:p></o:p></p></div></body></html>