----- Mensaje original -----
De: Filip Konvi?ka
It seems that accessing node_count using the same technique as with ordered_unique does not work - I'm off by 4 bytes (see the (((char*)&$c)+4) expression).
I've examined this carefully and I can't see how the offset should be needed. What's the value the visualizer shows without the offset, i.e. when using the following expression?
size : ((multi_index_helper_3<$T2>*)&$c)->node_count
It gives 3.
What is the correct value?
I've had a bad feeling about simulating multi_index_container structure before, and now it finally failed :-) I assume that it is because of structure alignment. When I did
(($T2*)(((char*)&$c)-4))->node_count
it worked well (i.e. assuming that the first member takes 4 bytes and casting back to the multi_index_container itself). That "4" can be probably calculated automatically, which involves the nasty trick with member pointers that I talked about earlier. But that involved a static int constant, so I'll stick to hard-coded 4 for now...
What worries me is that I don't have a clue why having a hashed index as the first one makes a difference... Maybe you should try with more indexed_by combinations, including more than one or two indices, to see if the scheme is robust enough. All in all, I'd say the (($T2*)(((char*)&$c)-4))->node_count approach looks safer than the +4 one, and AFAICS it should work regardless of the header_node type --can you try this?
I'm afraid traversing a hashed index is no easy chore. [...] OK, I looked into buckets.spc.data_, visualized it as an array (I assume that buckets.spc.n_ is the number of buckets),
Almost correct. Strictly speaking, that n_ is bucket_count()+1, as the last position is reserved for a faux bucket pointing to the header node --which is where end() in hashed indices points to.
and I got some hashed_index_node_impl nodes. I see that in some nodes, next_ points back to the node (empty bucket?),
Correct.
and with others there seems to be something more.
Yep, these are nonempty buckets. Elements are linked in a circular fashion, so you know you're finished with the bucket when you're back at the starting position in the bucket array.
I thought about the algorithm you describe, and I think that this is beyond what we can do (there is some #if ... #else ... stuff, but that is not recursive...). What I think we could do instead is to visualize the hashtable instead - display the buckets and their respective contents. A problem here might be that I don't know whether bucket item count is known.
See my comments about circular chaining above.
But let's deal with this later... (it's said that there's some anti-loop functionality in visualizer's list iterator, so let's see).
Do you think the visualizer is powerful enough to run this algorithm? If so, I can provide you with more details to begin writing the stuff.
If you can please tell me some info about the buckets.spc.data_ fields (if they really are the buckets, of course). What are the array members? hashed_index_node_impl?
The bucket array constains elements of type hashed_index_node_impl*. Note that these pointers cannot be downcast to proper hashed_index_nodes, that is, they don't hold values: only the elements they point to are genuine hashed_index_nodes. [...]
There's some techniques users can apply to reduce symbol name lengths, as explained at
http://boost.org/libs/multi_index/doc/ compiler_specifics.html#symbol_reduction
but there's little else to be done from your side in the case the user has not applied some of these techniques of her own accord.
Thanks for the info, I'll try the "intrusive" approach and see what it does to the visualizer (there will be probably a problem with the header_holder pattern...). (However....when a user does this, she can also adjust the visualizer, right?
I'm not getting your question, sorry. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo