LazQuadTree - a quadtree for Lazarurs/FreePascal

[EkkehardDomning]

I am happy and proud to announce my LazQuadTree class, a quadtree for Lazarurs/FreePascal

A quad-tree is a tree data structure in which each internal node has exactly four children.
The TLazQuadTree class allows the organization of arbitrary two dimensional data, for a quick access.
The class (and some helpers) are open for all kind of data, include the loading and writing to a file.
Descent access methods are defined to help the tree construction and analysis.
Several sample applications gives a fast impression about the functionality and may help building Your own applications.

The whole thing could be downloaded from https://gitlab.com/EkkehardDomning/lazquadtree.

[jamie]

Good work.

 At least you didn't cut any comments short!

Maybe you could create some Constants for the in lined Hex numbers you used in the Case statements for better reading later on.

 I also see opportunities for inlines functions for the Rect functions.


 

[EkkehardDomning]

Good work.
Thank you!

At least you didn't cut any comments short!
Yes. But the reason is more for myself, getting the code understood some days in the future, and to give me a chance to argue with users, who also not understand what the code actually is doing 

Maybe you could create some Constants for the in lined Hex numbers you used in the Case statements for better reading later on.
Usually I do so, but in case where you probably refecting too (ulazquadtreegeometry.pas) the gain will be probaly very small. One thing that annoys me in the Lazarus-IDE, is the missing format options in the variable observation dialog (F7). It would be nice to enter "lAreaAB,x" to see the variable formatted to "$A2C2" instead of "41666", which is almost useless in the specific case.

I also see opportunities for inlines functions for the Rect functions.
This might be a good idea. I am always a bit uncertain about this definition, since I like to avoid inflating the final executable code, but in some cases the opposite may be true. Please let me know where and what exactly you thinking about.

[marcov]

I also see opportunities for inlines functions for the Rect functions.
This might be a good idea. I am always a bit uncertain about this definition, since I like to avoid inflating the final executable code, but in some cases the opposite may be true. Please let me know where and what exactly you thinking about.

Compile to assembler, and see how big the procedure is, and how big the param parsing is on the place where it is called in a typical situation.

Then inline, go back to a typical usage pot, and see how large it looks now.