Sounds fun. I'm currently working on a personal project to put into my
online Github in order to show off to prospective employers, so it might
be a while before I get around to that.
On another note, I'm also still waiting on Pierre to approve my XML node
dump, since he and I have been doing a kind of iterative improvement
with each patch we make. It's been about a week now though since he's
responded. I do hope that gets implemented soon because using that to
help implement pure functions will be very useful. I have thought about
another place where pure functions in particular have an advantage when
coupled with a smart compiler - for example:
*for *X := 0 *to *Min(BUFFER_SIZE, DataLeft) *- 1 do*
*begin*
{ Do some work that doesn't modify DataLeft }
*end*;
Say that Min is given the *pure *directive, BUFFER_SIZE is a *const *and
DataLeft is a property or some non-local variable. Since no volatile
intrinsic is used to safeguard multi-threading issues, and DataLeft
isn't modified by the for-loop, DataLeft can be promoted to the stack or
a register. Even though its exact value is not known, DataLeft is
determined to be constant within the confines of the for-loop, hence
since both arguments in "Min(BUFFER_SIZE, DataLeft)" are constants, the
result must also be constant, since it's a pure function, therefore the
function only has to be called once and its result be stored on the
stack, recalled during each iteration of the for-loop. At least that's
the theory. Of course, you can just store the result yourself in a
local variable and use that as part of the for-loop, but it's just a
thought where pure functions could be used that doesn't involve
computing their result at compile-time.
Gareth aka. Kit
On 05/06/2019 16:11, Sven Barth via fpc-devel wrote:
J. Gareth Moreton <gar...@moreton-family.com
<mailto:gar...@moreton-family.com>> schrieb am Mi., 5. Juni 2019, 14:52:
Sounds fair. I would be trying for a refactoring approach, in
that the API and outward behaviour is identical to before (i.e. a
black box), but the inner workings are better. I noticed that one
potential source of improvement is changing the Quicksort
algorithm, used in most of the sorting, for Introsort
You could try to adjust the FGL unit to use the pluggable sorting
system introduced here:
https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&revision=41167
It's currently only used for the non generic TList and TFPList.
You could then add a IntroSort implementation.
Regards,
Sven
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
