Quoting Ion Gaztañaga:
The standard also allows allocator::size_type to be any type, so if I want to support building STL containers above Intrusive, I must somehow allow specifying the size_type for Intrusive.
Would returning std::size_t prevent somebody from building STL containers above Intrusive? If the allocator::size_type is so strange that you cannot convert a std::size_t to or from it, I'm not sure a common STL library would be able to use this allocator for its containers anyway. Perhaps I'm missing something.
Maybe it would be clearer with an example. The following pseudo-code is something I want to be able to write.
struct T { hook1; hook2; data }; iset<T,hook1> set1; iset<T,hook2> set2; ...; set2 = set1;
If sets are different types, operator= has no sense in my opinion,
They are only different because of the intrusiveness. They really are both sets with the same type T and the same ordering std::less<T>. So from a std::set point of view, they have the exact same type and it makes sense to have an assignment operator from one to the other. The code can already be correctly compiled if you write instead: set2.clear(); set2.insert(set1.begin(), set1.end()); But the insert operation is highly inefficient here, as the whole red-black tree is built from scratch for set2, with lots of balancing, although in the end it could have the exact same structure as the one from set1. Best regards, Guillaume