Ivan Matek wrote:
We may have a very specific use-case, but would you consider a small modification to the library inside "boost/icl/impl_config.hpp", in order to open the door for other set/map implementations?
I am unrelated to ICL, but I do not thing this is such a small change, if they would allow flat_* containers with O(n) insert time then they would probably need to update all the docs to specify complexity in terms of underlying container complexity, or just add an ugly hack to docs that notes that if you use your own container that then all complexity guarantees in docs are off. https://www.boost.org/doc/libs/1_64_0/libs/icl/doc/html/boost_icl/function_r...
That's a very good point, so much for the small patch then.
Also out of curiosity: did you try out the[google abseil b-tree](https://abseil.io/blog/20190812-btree)?
No we did not, but it may be worth trying it out too, thanks for the advice. Since our use-case revolves mostly around creating big interval sets, then adding, subtracting or traversing them (think selecting millions of items among billions of them, and adjusting that selection), the lesser memory footprint and increased cache-friendliness are good arguments. In the end we will probably end up rewriting something more suited to our needs. ICL provided a quick and easy way to implement it, but not optimised given the scale we use it at. Thank you for the feedback! Best regards, Martin