[fpc-devel] Standard generic classes

[J. Gareth Moreton]

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 <gareth at moreton-family.com 
> <mailto:gareth at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190605/23c03def/attachment.html>