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

From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2007-05-29 17:44:08

Filip Konvička <filip.konvicka <at> logis.cz> writes:
[...]
> Hm, I succeeded, in a way, in visualizing a indexed_by<sequenced<>, 
> hashed_unique<identity<T> > > container, but with some pointer 
> arithmetics and artificial classes derived from the container class in 
> the compiled code. I think that I'll abandon the clean solution path for 
> now, as with my current knowledge about autoexp.dat, the visualizer 
> language lacks some important type accessors, nor have I found a way to 
> do sub-patterns, either of which would probably enable proper 
> visualization of a generic multi_index_container.
> 
> As the visualizer language does not seem to enforce cast safety as C++ 
> does, I thought about using some raw pointer arithmetics to access the 
> nodes / data. I succeeded with the above-mentioned case, but when I 
> changed/added new indices, I was lost (I did not try that much, I admit...).

Doing the arithmetic blindly is impossible, since each index
adds some overhead to the overall node structure. I don't think
you can follow this approach.
 
>  From the "binary" point of view, is there some generic scheme that 
> could be used to access the elements in the container? One can access 
> node_count, but being able to display the list / array of elements would 
> be nice (I don't think that it's necessary to be able to display the 
> tree structure of ordered_unique, for instance), even if there are some 
> additional requirements like that there is a sequenced<> index or that 
> it is even the first of the indices.

If you don't mind relying on index #0 being a sequenced one, then
I think you can do it: the assumption about the first index being
sequenced is equivalent to specifying that the type of the
header node is of the form:

  sequenced_index_node<Q>*

where Q is some complex type involving the rest of indices as
well as the value type (that I call T1 according to your
convention when writing the visualizer). You already know how
to traverse a sequenced index, but just to document it again,
the expression to go from a node n (of a sequenced index) to the
following is:

 (sequenced_index_node<Q>*)
   (sequenced_index_node_trampoline<Q>*)
      ((sequenced_index_node_trampoline<Q>*)(n)->next_)

As for getting the value, the following will do:

  *(T1*)(index_node_base<T1>*)n;

The beautiful thing about this latter expression is that
it does not formally depend on Q, so I think you can
implement it in the visualizer, can't you?

If you're able to implement this (i.e. visualizing arbitrary
multi_index_containers with the only restriction that
the first index is sequenced) then maybe we can extend this
approach and work out how to eliminate the restriction and
handle the cases where the first index is ordered, hashed,
or random-access. But let's do the simple thing first.
Does this help?

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo