Question

I’ve been adding visualizers for some of our types to autoexp.dat.
Even with that blog that everyone refers back to (even the microsoft guys!) it’s been a struggle at times.

But I’m completely stumped by the #tree visualizer. First that blog post seems to be full of holes in its description of it (and no other material I’ve been able to find addresses that – but others have clearly got it working). In particular there seems to be some magical cases where it knows to dereference a pointer – but I can’t be sure I’ve reverse engineered the intent.
Also there seems to be some ambiguity between when you use $c and $e. AFAICS they appear to be interchangeable – perhaps both are allowed as an aid to readability? Or do they really mean different things (that blog, for example, uses $e where the stl visualizers that come with VS2008 use $c).

But what’s really missing is an explanation of how it all fits together. I would have imagined it would follow this process:

1. Apply the “head” rule to get to the starting node (by pointer)
2. Apply the deref rule (the bit at the end) to the dereferenced current node to get the value for visualising.
3. Apply the left and right rules to the dereferenced current node to get to the left and right nodes, respectively (by pointer – with null as a terminator, unless a skip rule is specified).
4. Go to (2) until all nodes have been visited.

Obviously there’s an algorithm for navigating left/ right there that I have glossed over. That’s not too important. What’s more important is which values are considered at each stage and when dereferencing happens.

That seems to be the only process I can imagine that fits the examples I’ve seen. But I’ve been unable to get it to work with our tree implementation. I just get (error) where the #tree children should be displayed (I do get one (error) for each node, so I presume the size is being captured correctly). I’ve tried ever possible variation I can think of – most several times!

The other thing that puzzles me is that many examples I’ve seen, including the bundled stl ones, navigate from head to parent (or similar), and skip the head node. Why do they do that?

Here’s the visualiser I’m using (in one of the forms I’ve tried – and the names have been changed to protected the … corporate):

MyTree<*,*,*>{
    children(
        #(
            [raw members]: [$c,!],
            #tree
            (
                head : $c.m_root.m_p,
                size : $c.m_size,
                left : left.m_p,
                right : right.m_p
            ) : $e.value
        )
    )
}

And here’s some pseudo-code for my tree classes:

MyTree:
    Ptr<Note> m_root
    int m_size

Node:
    ValueT value
    Ptr<Node> left
    Ptr<Node> right

… where Ptr<> is a smart pointer, holding the raw pointer in m_p.

Any help would be greatly appreciated.

Answer 1

We started really really needing this! So I opened a bounty but carried on looking at it myself.

Looks like I’ve solved it! (for my case). I was actually pretty close:

MyTree<*,*,*>{
    children(
        #(
            [raw members]: [$c,!],
            #tree
            (
                head : $c.m_root.m_p,
                size : $c.m_size,
                left : left,
                right : right
            ) : $e.value
        )
    )
}

The trick is that the head rule needs to fully specify how to get to the raw pointer within the smart pointer but the left/ right rules do not (and neither does the de-ref rule).