<p>Am 10.10.2015 18:19 schrieb "Maciej Izak" <<a href="mailto:hnb.code@gmail.com">hnb.code@gmail.com</a>>:<br>
> class operator TSmartPtr<T>.Copy(constref aSource: TSmartPtr<T>; var aDest: TSmartPtr<T>);<br>
> begin<br>
>   if aDest.RefCount <> nil then<br>
>     Finalize(aDest);<br>
>   if aSource.RefCount <> nil then<br>
>     InterLockedIncrement(aSource.RefCount^);<br>
>   aDest.RefCount := aSource.RefCount;<br>
>   aDest.Instance := aSource.Instance;<br>
> end;</p>
<p>Shouldn't it be SmartFinalize here as well instead of Finalize?</p>
<p>> 2015-10-10 9:59 GMT+02:00 Sven Barth <<a href="mailto:pascaldragon@googlemail.com">pascaldragon@googlemail.com</a>>:<br>
>><br>
>> Would you please explain why you'd need this raw structure besides for printing the RecCounts? (honest question, maybe I'm still too tired ;) )<br>
><br>
> There is no way to access RecCount from TSmartPtr. When is used "default" inside TSmartPtr (or inside any other record), TSmartPtr works only as proxy object to "Instance" field. (!) but to perform functionality is necessary to treat Implicit and Explicit operators as operators with higher priority than "default" field, an example:</p>
<p>Ah, yes, now I see.</p>
<p>> !!! WARNING -> Explicit and Implicit in that case is different than standard Explicit / Implicit. To be precise we have two new operators:<br>
><br>
> ===begin code===<br>
> operator Explicit: A; <br>
> operator Implicit(const Value: B);<br>
> // there is no class keyword before declaration, look at example implementation of TSmartPtr<br>
> ===end code===<br>
><br>
> these two operators have a higher priority than "default" field, and "default" field have higher priority than any other field/property/operator/method/const/type inside record structure. When "default" is used for field then we don't have direct access to record. New variant of Explicit operator and raw structure is IMO elegant way to get access for original record fields.</p>
<p>Playing around with priorities can be a PITA as well, so be careful ;)</p>
<p>>><br>
>> This is where we reach the dangerous territory ;)<br>
>> The problem with "default" is how to differentiate from a normal field usage of the record? Keep in mind that a feature might be used in different contexts than one first imagined. So how to ensure that one can access field X of the record and not field X of the default?<br>
><br>
> I know it is risky :P. In attached proposition, problem of overloading operators like "@", ".", "^" is omitted. You need to start thinking about "default" as proxy. Mentioned problem don't exist because programmer can access only "Instance" field (but not directly, for this is used "compiler magic"). The only place where exist access to record structures is implementation of this record. From implementation is possible access to any field or property. Inside implementation of record with "default" field, "default" field has no effect:</p>
<p>While I see and understand your reasoning behind it I don't really like it... There needs to be some better way for this... hmm... :/</p>
<p>>> Only behind a modeswitch or maybe even a mode Oxygene please. And take care with prefixes, they are a PITA to handle as I've already told you ;)<br>
><br>
> do not scare me!</p>
<p>Who? Me?! Never! :P</p>
<p>Regards,<br>
Sven</p>