Re: [boost] [intrusive] Review

From: Guillaume Melquiond (guillaume.melquiond_at_[hidden])
Date: 2007-03-20 14:13:17

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