OK, here is a visualizer for multi_index_container
> >. I have not succeeded in expanding this to other index combinations, as the visualizer does not seem to support "::type" to access typedefs. When I want to access the "member" member of the container, I need to explicitly specify the header_holder template instantiation, which seems impossible, since it takes - as the first argument - an index_node type structure, which seems to be declared as boost::multi_index::detail::multi_index_node_type
::type, but this is not accessible in the visualizer (it does not like the "::type" part). I'm afraid that there's no way around this, but I'll try tomorrow. 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...). 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. I was also thinking whether it would be possible to somehow augment the multi_index_container class with some helper structures to help the visualizer, however I don't see how that could be done. Such class could for example contain a linked list of all nodes (like the sequenced<> index does, but this time this would be non-optional and accessible in a type-uniform way). Thanks for any ideas :-) Cheers, Filip