how to view inheritance hierachy in C++?

[catphive]

One thing that has been driving me nuts is that it's difficult to determine the inheritance hierarchy. I'm working with a very large C++ project with lots of complicated inheritance hierarchies. Right now to find out what classes inherit from a given class I have to do a "find references" and sift through a huge number of irrelevant entries that merely reference the class name.

It seems like given that slickedit indexes my code base it should have inheritance graph information, but I can't seem to find this in the UI... Really, it seems obvious that I'd want some kind of graph.

Another thing that bugs me is that I'm not clear on the distinction between the Symbols, Class, and Defs sidebars. They all seem to contain more or less the same information...

[Wanderer]

It's old and not all that well maintained, but I find Source Navigator (http://sourcenav.sourceforge.net/) very useful for understanding class relationships.  It shows which members are inherited, which are public, which are overridden, etc.

[ScottW, VP of Dev]

Try the Class Tool Window: select View > Tool Windows and put a check next "Class".  This tool window contains some of the same information you would see in the Defs tool window, but it also has a hierarchy browser in the top pane, which shows the inheritance structure (see the attachment). Because it is rendered as a tree, it can only show from the selected class up or from the selected class down. The arrows allow you to select which.

We'd like to offer a more graphical presentation for this. To do that we need to find a cross-platform graphing library that will work on all 7 of our supported platforms. We're doing some preliminary work on that.

The Defs tool window shows the definitions for all of the elements in the current file. It contains many options to filter and order the information provided. The Class tool window is very similar, but is customized to better suit object-oriented code. The Symbols tool window is a browser for all of the symbol information contained in the tagging database. It allows you to search/filter the list of symbols. Once you have expanded a particular symbol, you will see much the same information as presented in the Defs or Class tool windows.

I prefer to use the Class tool window with my OO code, the Defs tool window for non-OO code, and the Symbols tool window for general symbol lookup or browsing.

[catphive]

Ah, ok. The problem I have then is that nothing shows up in the base classes pane. It is blank. The pane below it that shows class members as a hierarchy works though.

Another thing is that even if this worked, I'm not sure it does quite what I want. It's good to show the base classes of my current class, but what I want to see as well are the derived classes. I want to see the whole inheritance hierarchy in which it takes part. Currently, finding what classes derive from the class I'm looking at is very tedious, and involves sifting through all references, which frankly isn't that much better than running a grep.

SlickEdit Version 14.0.1.2

Serial number: VML110308
Licensed number of users: Single user
License file: /opt/slickedit/bin/slickedit.lic

Build Date: May 15, 2009
Emulation: CUA

OS: Linux
OS Version: Ubuntu 9.04
Kernel Level: 2.6.28-13-generic
Build Version: #45-Ubuntu SMP Tue Jun 30 19:49:51 UTC 2009
X Server Vendor: The X.Org Foundation

Installation Directory: /opt/slickedit/
Configuration Directory: /home/brenmill/.slickedit/14.0.1/
Spill File: /tmp/$slk.brenmill.27397

[chrisant]

The base class window seems to only show anything if the cursor is on a function/member within a class.  Otherwise it's empty.  Being on the "class Foo" line does not put anything in the base class window, and selecting a specific class in the lower pane of the Class toolbar does not put anything in the base class window.  The base class window would be more useful if it were easier to get something to show up in it.  Ideally you could explicitly examine a specific class even if your cursor were in a different class.

The base class window also only shows base classes.  It's good for browsing bases, but if there were a way to explore derived classes, that would be even more useful.  I imagine that finding the derived classes might be an unkeyed Btree lookup, so probably have a button that triggers it so the user has control over when the application goes non-responsive (and probably expand only one level of derived classes at a time).  And some classes could have excessively large sets of derived classes (e.g. CObject in MFC) so it seems quite reasonable to have a cutoff for how many derived classes to list (with a way to see more if necesary -- perhaps via the References toolbar, see related note below).

I don't care about a graph at all -- a treeview control is perfectly fine (in some ways preferable, even!) as long as it shows both base classes and derived classes.



On a related note, it would be excellent to be able to restrict the kinds of references found when using the References toolbar.  For example "find references inheriting from X" or "find references where X is read from" or "find references where X is written to" (of course passing by reference or as a pointer out-parameter is ambiguous and matches either), stuff like that.

[ScottW, VP of Dev]

Yes, the cursor must be positioned on a symbol that is a class for that pane to show content. I misspoke about the arrows switching between derived and base classes. You can get that information by doing the following:
1) Select a class in the hierarchy pane (top pane).
2) Right-click and select "Show <class> in Symbol browser".
3) In the Symbols tool window, which should now be visible, right-click the class and select either "Base Classes" or "Derived Classes".

...and yes, that seems like a long way to go for that. I'll see what we can do to make that more accessible.

[chrisant]

Oh, hot!  Thanks, Scott, yes those Base/Derived Classes windows are great, I had never managed to find them.    One or more entry points from places other than the Symbol Browser would be great.


I'd like to use the Symbol Browser and learn more about it, but I don't for a few reasons:

• It gives a huge list when nothing is specified, which I assume (perhaps falsely) can cause delays in the editor while it fills the list.
• The Class and Member dropdowns leave me confused:  What if I want to filter by a namespace?  Or by a class that's embedded in another class?  Or something that is neither a class nor a member, such as a global variable?  I'd expect a single filter box, and either checkboxes or text markup to control the filtering (e.g. "class:Foo member:x" or "c:Foo m:x" or "Foo::*" or etc).
• Filtering doesn't happen as I type (although in large projects the filtering might be too slow to filter dynamically).
• Most imporant of all:  When I filter, the symbol browser leaves lots of collapsed header entries in the treeview.  There are so many that unless the symbol browser is very tall, I have to scroll the treeview just to find the matches.  I'm much too lazy for that. 

So I use Find Symbol instead, and never use the Symbol Browser.  I suspect I'm missing out on some great features (like the Base Classes and Derived Classes windows) just because of the quirks above.

[Ryan]

The base class window seems to only show anything if the cursor is on a function/member within a class.

Right...your cursor has to be within a class in order to see the base classes pane populated.  The tool window keys off the current cursor position, like the Defs window.

The base class window would be more useful if it were easier to get something to show up in it.  Ideally you could explicitly examine a specific class even if your cursor were in a different class.

The Class tool window was originally intended as a more object-oriented view of the Defs window, which would also show you what methods/functions are available from base classes.  I think if you are typing in specific class names that you want information about, you probably want to be using the Symbols tool window at that point.  Though maybe we could add a combo box which you could type in, in order to quickly jump to and view the desired class...

It's good for browsing bases, but if there were a way to explore derived classes, that would be even more useful.

We could easily put a context menu on that tool window to show the "Derived Classes" pane for any class that you select.  We thought that this would be more of an "on demand" operation, rather than something people would constantly want updating and changing as they moved around.  It's more expensive, and when you have it showing the base classes it shows you methods or functions which are (possibly) available to you in your current class which you would otherwise not see in the Defs window.

Also...

Because it is rendered as a tree, it can only show from the selected class up or from the selected class down. The arrows allow you to select which.

The arrows are actually for jumping up and down the hierarchy, pushing bookmarks in the editor along the way:  the same as double-clicking down the tree.

- Ryan

[catphive]

Ah, I've got your trick to show derived classes through the symbol sidebar working thanks.

However, I still can't get the base classes pane to work at all. Not even if I click on the class name in the text editor, etc. The base classes pane is just *always* empty, and I had no idea what it was for. This looks a lot like a bug to me.

SlickEdit Version 14.0.1.2

Serial number: VML110308
Licensed number of users: Single user
License file: /opt/slickedit/bin/slickedit.lic

Build Date: May 15, 2009
Emulation: CUA

OS: Linux
OS Version: Ubuntu 9.04
Kernel Level: 2.6.28-13-generic
Build Version: #45-Ubuntu SMP Tue Jun 30 19:49:51 UTC 2009
X Server Vendor: The X.Org Foundation

Installation Directory: /opt/slickedit/
Configuration Directory: /home/brenmill/.slickedit/14.0.1/
Spill File: /tmp/$slk.brenmill.27397

[chrisant]

I've been playing with the Symbol Browser more:

1.  I had a Slick-C project open, and used the Symbol Browser.  I opened a C++ project instead, right clicked a class name in a file and chose "Show {symbol} in Symbol Browser", and it couldn't be found.  It took me a while to realize the Symbol Browser was still showing symbols from the previous project, instead of from the current project.  At some point it caught up and started showing symbols from the current project, but I'm not sure what I did that updated it.

2.  The "Calls or uses..." command is intriguing, but I wonder if there is a bug:  When I select a class method in the Symbol Browser, then right click and choose "Calls or uses..." then it seems to look up calls/uses of the class itself, rather than the method.  I got the same behavior opening the call tree window on a class method (e.g. Object::Free) via context menu from Symbol Browser, and via context menu from Defs window.  (The Help says that for a function it shows everything called/used by the function).

3.  Dueling with the Preview toolbar.  I work on a laptop, and don't have tons of extra screen real estate for toolbars, so I have things like Preview and References set to Auto-Hide (docked at the bottom).  I have the Defs/Class/Symbols toolbars always visible (docked together as tabs on the left).  I want the Preview window to show symbols I'm looking at.  But with this arrangement the Preview window pops up and obscures the lower part of the Defs/Class/Symbols toolbar.  I wish that I could dock+autohide the Preview window below the MDI client area, but without extending all the way to the left edge.  See attached screen shots.

[ScottW, VP of Dev]

@chrisant:
1) Not sure what's going on there. Let us know if it's always like that. Might have just needed to fill the cache.

2) This shows what the selected symbol calls are uses--not the places the selected symbol is called or used. Selecting this on a method should show what symbols that method calls or uses. It works fine in my testing.

3) Good feedback, but currently beyond what our window manager can handle. We're updating the window code and I'll pass this along.

[chrisant]

1) Not sure what's going on there. Let us know if it's always like that. Might have just needed to fill the cache.

Seems to be 100% reproducible for me.
1.  Launch SE, autorestores previous project.
2.  Right click on a symbol in a file window, choose "Show {symbol} in Symbol Browser".
3.  Open a different project.
4.  Right click on a symbol in a file window, choose "Show {symbol} in Symbol Browser".
Result = Symbol Browser comes up with the previous project's vtg shown, the symbol from step 2 is still shown.
Expected = Symbol Browser comes up with the vtg from project from step 3 shown, and symbol from step 4 is shown.

@chrisant:
2) This shows what the selected symbol calls are uses--not the places the selected symbol is called or used. Selecting this on a method should show what symbols that method calls or uses. It works fine in my testing.

Right, I get that.  I tried to reproduce the behavior again, but it's working now.

Except that in the attached repro cause, the root node always shows as "HelloWFoo" until the "Foo" node below it is expanded, and then if you re-select the root node then it paints as "HelloWorld()   Foo".  See the repro.cpp in the attached Zip file for details.  I've seen similar paint problems in treeviews used by my own macros, but I thought maybe I was doing something wrong.  Now that I'm seeing it in a stock treeview, too, maybe it's a little nit bug somewhere in the treeview code that can be fixed easily with a consistent repro case.  *fingers crossed* 

Anyway, the behavior I had been seeing 100% consistently yesterday was that if I right clicked on "MethodName()" under a "Foo" class in the Symbol Browser and chose "Calls or uses..." from the context menu, then the Call Tree dialog showed "Foo" (the class!) instead of "MethodName()" (the function), and showed me everything used by the class Foo, instead of showing me everything used by the function Foo::MethodName.  I'll probably use the "Calls or uses..." more in the future, and I'll keep an eye out for consistent repro steps, so the problem can be diagnosed/etc.

3) Good feedback, but currently beyond what our window manager can handle. We're updating the window code and I'll pass this along.

Understood, thanks.

[LBCEi]

re: chrisant's item #3

The behavior seems a bit strange since, when not auto-hiding, the bottom docked toolbars don't extend all the way to the left (see screenshot).  When set to auto-hide, the same toolbars do extend across the entire window and, when un-hidden, obscure the left docked toolbars.  I'm sure there is a reason, but it seems a bit odd.  Perhaps there is a different docking configuration that wouldn't cause this odd behavior?

Regards
Les

[ScottW, VP of Dev]

@chrisant: on item #1, I can't reproduce that. When I switch workspaces, the Symbol tool window is immediately cleared and then a new unexpanded "Workspace" item is listed. In step #3, you say "Open a different project". Do you mean "Open a different workspace?" Can you give more details about this step. Maybe you're doing something different than I am doing.

Can you reproduce this with a default config? I know you've made some mods to SlickEdit, so I wonder if those might be causing this too.

[chrisant]

@chrisant: on item #1, I can't reproduce that. When I switch workspaces, the Symbol tool window is immediately cleared and then a new unexpanded "Workspace" item is listed. In step #3, you say "Open a different project". Do you mean "Open a different workspace?" Can you give more details about this step. Maybe you're doing something different than I am doing.

Can you reproduce this with a default config? I know you've made some mods to SlickEdit, so I wonder if those might be causing this too.

Oops, yes in steps 1 and 3 I meant "workspace" not "project".  My mods are set up so I can turn them on/off at will (and I haven't patched this kind of stuff yet).  To be sure, for issue #1 I'll make a self contained repro using two workspaces and a stock install with fresh config.  For issue #2 I'll revise the repro with clearer steps.  Will reply back later when I have the details.