Re: [Boost-users] [multi_index] MSVS 2005 visualizers?

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2007-06-02 07:47:36

----- Mensaje original -----
De: Filip Konvi?ka <filip.konvicka_at_[hidden]>
Fecha: Sábado, Junio 2, 2007 0:27 am
Asunto: Re: [Boost-users] [multi_index] MSVS 2005 visualizers?
Para: boost-users_at_[hidden]

> > > 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