[fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

[Maciej Izak]

2018-04-29 21:26 GMT+02:00 Anthony Walter <sysrpl at gmail.com>:

> I wanted to know from the people who make decision about what to merge,
> what's the status of rolling his enhancements at following location into
> FPC trunk?
>

The key part of smart pointers (management operators) is already in trunk
(as Sven said). Btw. you forgot about AddRef operator ;)

The problem is more complicated than just "merge" for "default field".

*** part 1 ***

The first problem is slowdown for constructors for classes (which already
is part of trunk, trunk is a little slower than 3.0.x for constructors).
The main reason of " slowdown" is new feature "management operators". The
solution (and improvement) is FastRTTI which is designed for management
operators and all managed types:

https://github.com/maciej-izak/freepascal/tree/fastrtti

with these patch FPC is faster for all classes/records/objects with managed
types. This patch is not only designed as patch for constructors but the
gain is more general, for all managed types the result is really good - the
execution of code is even few times faster when you use a lot of managed
types. Compiler compilation with FastRTTI is always faster around 1%-3%
(where usage of managed types is rather rare). The hardest part for me of
implementation of FastRTTI was testing (I don't use AVR nor i8086 nor m68k)
, but this is ready:

https://travis-ci.org/maciej-izak/fpc-ci-tests/builds/320484
786?utm_source=email&utm_medium=notification

this part was really depressing :P. The last thing what I must finish is
renaming "holes" to "unmanaged_spaces" x) (personally I prefer the "holes"
but I must agree with Sven that the "holes" term is not perfect).

*** part 2 ***

The default field. The topic is complicated on many fields, but generally
we have 2 issues, raised by Jonas :

- existence of @@ and @@@ operators:

https://github.com/maciej-izak/PascalSmartPointers/blob/mast
er/tests/tdefaultfield6.pp
https://github.com/maciej-izak/PascalSmartPointers/blob/mast
er/tests/tdefaultfield14.pp
https://github.com/maciej-izak/PascalSmartPointers/blob/mast
er/tests/tdefaultfield21.pp
https://github.com/maciej-izak/PascalSmartPointers/blob/mast
er/tests/tdefaultfield22.pp

- handling procedures/methods parameters (especially for var/out which is
not listed below)

https://github.com/maciej-izak/PascalSmartPointers/blob/mast
er/tests/tdefaultfield25.pp
https://github.com/maciej-izak/PascalSmartPointers/blob/mast
er/tests/tdefaultfield26.pp

as solution was proposed new type kind, but IMO new kind just for default
field is redundant. What with further usage of "default field" for classes
and objects (maybe now it looks like nonsense but should be usefully with
ARC combination with classes)? Again new types? I don't wan't to lock this
path (default field for classes and objects).

possible alternative is "strict" modifier

https://github.com/maciej-izak/PascalSmartPointers/blob/mast
er/tests/tdefaultfield30.pp

"strict default" may be the solution, the record with "strict default" may
have more strict policy in compiler to make all of us happy. If someone
needs to use "default field" as more advanced precise helpers - just use
"default". If strict policy is more important (like for Jonas, some part of
me agree with him) then use "strict default".

Technically all for smart pointers is ready.

-- 
Best regards,
Maciej Izak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20180430/b263d70e/attachment.html>