2018-04-29 21:26 GMT+02:00 Anthony Walter <sys...@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
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
