Hi Henri, Henri Bavestrello wrote:
unfortunately as during looking-up phases I had to create a whole dummy ojbect initialized with the key searched for to be able to use the imultiset::find method; I decided to implement an intrusive map (imap) modifying the red-black tree implementation that comes with the library, something like:
[snip] I am happy to see that with this new version of the library, I can directly use the iset container taking advantage of the find(key, comp) method ;-). Also, the iset container instantiation is simpler as the Compare operator actually combines the comparison operator and the key extractor.
These new comparison/search functions were added for this and to make possible building map-like non-intrusive containers, where just the key part is used to search the data. I would be interested in the avl code you have used in your example. It would be nice to have avl_tree_algorithms in the library, and we could even make an intrusive associative container based on that tree. Contributions are welcome ;-)
It may be help full in the example about the iset/imultiset container that the two container uses different type (currently they both use MyClass int_ data member as key), and make use of the iset/imultiset::find(key, comp) method.
Those advanced functions are explained in the next section, so I don't if including them in the previous example would be logical. I'll think about it.
- Are you knowledgeable about the problem domain? I am no expert on containers, but as a user in the HPC community, I well aware of problems like data locality and cache trashing.
Any suggestion from HPC people is well received ;-)
- Do you think the library should be accepted as a Boost library? Yes. I will definitively use it; and as an other review wrote, I will maintained my own copy, it is not ...
Thanks for your vote. I hope we can continue improving Intrusive for HPC needs.
Best regards, Henri.
Regards, Ion