Filip Konvička
Hm, I succeeded, in a way, in visualizing a indexed_by
, hashed_unique > 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