[fpc-devel] Pascal Smart Pointers Idea + ARC implementation

[Sven Barth]

Am 10.10.2015 18:19 schrieb "Maciej Izak" <hnb.code at gmail.com>:
> class operator TSmartPtr<T>.Copy(constref aSource: TSmartPtr<T>; var
aDest: TSmartPtr<T>);
> begin
>   if aDest.RefCount <> nil then
>     Finalize(aDest);
>   if aSource.RefCount <> nil then
>     InterLockedIncrement(aSource.RefCount^);
>   aDest.RefCount := aSource.RefCount;
>   aDest.Instance := aSource.Instance;
> end;

Shouldn't it be SmartFinalize here as well instead of Finalize?

> 2015-10-10 9:59 GMT+02:00 Sven Barth <pascaldragon at googlemail.com>:
>>
>> Would you please explain why you'd need this raw structure besides for
printing the RecCounts? (honest question, maybe I'm still too tired ;) )
>
> 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:

Ah, yes, now I see.

> !!! WARNING -> Explicit and Implicit in that case is different than
standard Explicit / Implicit. To be precise we have two new operators:
>
> ===begin code===
> operator Explicit: A;
> operator Implicit(const Value: B);
> // there is no class keyword before declaration, look at example
implementation of TSmartPtr
> ===end code===
>
> 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.

Playing around with priorities can be a PITA as well, so be careful ;)

>>
>> This is where we reach the dangerous territory ;)
>> 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?
>
> 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:

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... :/

>> 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 ;)
>
> do not scare me!

Who? Me?! Never! :P

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20151010/740f8e56/attachment.html>