> The generic functions are very powerful and model closely the C++ STL > library (as fpc does not have generics yet a sort of typecast is still > required when fetching the items from the container). The library was > not designed for speed though, from the first test the DArray class is > twice as slow then the TFPList for example). Anyway, I think it's a > good start, since as I've seen from the wiki, we'll not have generics in > fpc available soon (I would be glad to contribute to the generics > implementation, but this but is still beyond my current poor fpc > knowledge :( ) . When our compiler will support generics, if Decal will > be fully covered by unit tests I think it will be easier to convert to it.
At work, I have found out that decal is too bulky and too slow for some purposes (I've lists with millions of objects in memory). _each_ entry in a decal container eats 78 byte (with D6 memory manager, but will only be equal or larger with FPC) For this, I implemented dirty, but very fast maps and sets. These are not generic, but fast, and with FPC they can really fly due to inline capabilities. See http://www.stack.nl/~marcov/lightcontainers.zip > projects/contrib/decal. I've began to clean the unit to make it more > readable, moving the comments in a fpdoc xml file and restoring a proper > indentation. I have a tex version of the decal docs somewhere. http://www.stack.nl/~marcov/decal.tex (might use some FPC tex docs files) compiled to http://www.stack.nl/~marcov/decal.pdf _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
