Another thing I forget to mention. Since I was looking at management operator stuff in the compiler I was curious, why don’t classes support management operators? The infrastructure is already there for built-in reference types like dynamic arrays/ansistring’s so it would be relatively trivial to support classes also. I already spent a good amount of time working on “default properties” but that was done in leu of the fact that only records support management operators.

Regards,
Ryan Joseph

Ryan, I believe the compiler already has management support for complex types. That is for BOTH records and classes. All that is required is you have a supported version of the compiler and you add the sugar in the form of AddRef, Initialize, and Finalize. See this page for more information:

http://wiki.freepascal.org/management_operators

Exactly, it’s already there it’s just not supported for classes until a little extra work is done (even interfaces use it). I guess it’s under scrutiny now but I just made some changes so management operators work for old-style objects and noticed it would be fairly trivial to add support to classes also. Not sure why this wasn’t done in the first place because it makes ARC style memory management possible without record wrappers and default properties.

Regards,
Ryan Joseph

Ryan Joseph schrieb am Fr., 24. Mai 2019,
17:43:

This is not desired, because it would mean that for *all* assignments between *any* class type it must be at least checked for management operators or it must be forbidden that a class type with management operators can be assigned to a variable of a parent class that does not have them.
The former is definitely not desired, because it means a performance impact for otherwise cheap assignment. And the later can become annoying as hell when you want to pass an instance e.g. to a TNotifyEvent or store it in a TStringList's Objects property.

Regards,
Sven

On May 24, 2019, at 1:17 PM, Sven Barth via fpc-devel wrote: This is not desired, because it would mean that for *all* assignments between *any* class type it must be at least checked for management operators or it must be forbidden that a class type with management operators can be assigned to a variable of a parent class that does not have them. The former is definitely not desired, because it means a performance impact for otherwise cheap assignment. And the later can become annoying as hell when you want to pass an instance e.g. to a TNotifyEvent or store it in a TStringList's Objects property.

Isn’t this what fully ARC languages like Swift do though? I would think this would be an interesting option to at least be available for particular use cases.

Regards,
Ryan Joseph

Ryan Joseph schrieb am Fr., 24. Mai 2019,
22:26:

Object Pascal isn't a full ARC language however. Also it is not something that one can enable on a whim cause it also affects other parts.

Regards,
Sven

On May 24, 2019, at 2:46 PM, Sven Barth via fpc-devel wrote: Object Pascal isn't a full ARC language however. Also it is not something that one can enable on a whim cause it also affects other parts.

Isn’t that how the ref counted compilers types like pchar work? I was thinking enabling management operators for classes would have basically the same performance impact as those compiler types (which is actual ARC in Pascal unless I misunderstand).

Regards,
Ryan Joseph

Op 2019-05-25 om 19:24 schreef Ryan Joseph:

> On May 24, 2019, at 2:46 PM, Sven Barth via fpc-devel wrote: > > Object Pascal isn't a full ARC language however. Also it is not something that one can enable on a whim cause it also affects other parts. Isn’t that how the ref counted compilers types like pchar work?

pchar isn't refcounted. If you mean ansistring, that is not RTL based, but compiler based.

Ryan Joseph schrieb am Sa., 25. Mai 2019,
19:55:

First of as Marco said PChar isn't a managed type.

Second especially for the simple types (so no records, no matter if management operator or not) the compiler calls direct helper functions that deal with the reference count management being much faster than what is routed through the RTL's functionality.

Thus, if we would decide to implement ARC for classes we would integrate directly inside the compiler, cause there would be no need for user management (Create and Destroy have the role of the Initialize and Finalize operators). An experiment for this you can see in my old ARC branch which used a keyword (and had similar problems for passing to non-ARC classes, though it allowed to manually increase/decrease the reference count as well): https://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/svenbarth/arc/

Regards,
Sven

On May 26, 2019, at 4:02 AM, Sven Barth via fpc-devel wrote: Thus, if we would decide to implement ARC for classes we would integrate directly inside the compiler, cause there would be no need for user management (Create and Destroy have the role of the Initialize and Finalize operators). An experiment for this you can see in my old ARC branch which used a keyword (and had similar problems for passing to non-ARC classes, though it allowed to manually increase/decrease the reference count as well): https://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/svenbarth/arc/

Oh ok, I thought the management operators were basically just making a single additional call to the class method and were basically the same as ansistring ref counting. It looks like there is a main dispatch function (fpc_Initialize for example) that routes to variety of different functions based on the type and could simply be extended like it was for records. I liked the idea of management operators for classes because users can opt in for classes that aren’t doing performance critical stuff.

Regards,
Ryan Joseph