| Author |
 Topic  |
|
|
carnitron
Junior Member
17 Posts |
 Posted - Jun 12 2007 : 3:03:38 PM
|
It would be great to see a header file browser that would enable developers to:
1. See all of the .cpp files a .h file ultimately gets included into.
2. See all of the .h files a .cpp file ultimately includes.
Seeing this output in a browsable hierarchical tree control, like the current Object Browser, or via a V-Tune like graph (or both) would be ideal.
If such a feature was dynamically browsable, it would be cool if it signaled the user (maybe via a color change in the browse window) if a .cpp file does not need a given .h file that is included in it. This isn't the kind of thing you'd want to warn about at compile time, b/c in some cases including unused header files is accpetable.
This tool would be helpful for:
1. Minimizing compile times.
2. Maximizing data hiding.
3. Combatting code decay.
Frankly, I'm sort of puzzled why such a tool does not see widespread application already -- it seems like one of those simple ideas that nearly everyone would use. Are there tools that do this kind of thing already? (And even if there are, do they do as good a job as VAX would do? :)
Cheers,
Peter Green
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jun 12 2007 : 4:12:29 PM
|
You could have a look at this: http://www.codeproject.com/tools/includefinder.asp
I always thought the idea was interesting, but I never managed to get the tool to run successfully on my projects. Perhaps I just did not spend long enough with it.
There is a related discussion in this thread:
http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=6178
Certainly this thread discusses the idea of "this header is no longer required". I am not automatically against the idea, but I do have some significant concerns about how we could do this properly. |
zen is the art of being at one with the two'ness |
 |
|
|
schoenherr
Tomato Guru
Germany
160 Posts |
Posted - Jun 13 2007 : 12:50:28 AM
|
not knowing your codebase i can only take existing features into account. remembering the "goto definition" and "find reference" feature i would suspect that you already have a very good picture of the set of included header files.
so at least the tree view should be possible to implement on top of existing informations.
the highlighting of unused header files possibly would be much more difficult, but i would call it a "nice to have" feature.
Seeing a visual representation of the include structure of a source file would definitly be a very useful feature at its own.
So i vote for this suggestion.
cheers
|
|
|
|
graham.reeds
Ketchup Master
United Kingdom
51 Posts |
Posted - Jun 13 2007 : 03:50:15 AM
|
I started a project like this a while ago, forking off the code found in Large Scale C++ Software Design (Lakos96). Didn't get very far as real work go in the way of any serious development. What I did manage to do was bring it up to modern C++ standard (using standard string), remove it's reliance on strstream and added more dialog.
My goals for the project consisted of:
a) Use current STL instead of own developed methods (completed)
b) Find headers that were incorrectly included (partially completed)
c) Suggest replacement for included headers where foward declarations would be better (very buggy).
d) Compile as an add-in for VC2K5 (started but C++/CLR ain't my thing!)
e) Sell it and retire early (failed miserably).
G. |
|
|
|
sl@sh
Tomato Guru
Switzerland
204 Posts |
Posted - Jun 13 2007 : 04:26:58 AM
|
Not sure I understand your objective correctly, but here I go:
Item 1 basically means finding reverse dependencies. I am not sure how knowing about those could possibly help you optimizing any aspect of design, development, or even maintenance. If I see one particular class' header file gets included extraordinarily often then it just tells me that this is an extraordinarily useful class! Why should I need to care, then, about this information? Moreover, a class interface (and any header file for that matter) should not care about being included a lot. If you believe there may be a problem caused just by the fact this header gets included often, then probably there is a problem with that header, not the #includes! (can you say 'nested includes'?)
If you want this feature in case you want to rename renaming header files, then you probably want to change the existing #include statements. That can be better achieved via the "find in files" function.
If ever you find a header that is not being included at all then this also means the compiler will never even look at it, let alone the linker.
Item 2 - As feline pointed out there was a discussion in that general direction. I'm all for improving the means to help on this issue, but I'm also wary of traps and exceptions an automized algorithm would need to catch. Especially the point feline brought up in the abovementioned thread about conditional #includes is a big can of worms all by itself. That said, I am convinced a good tool would require a lot of interaction with the user, just to make sure it does what it's supposed to do. That's certainly doable, but I don't neccessarily see this within the realm of VA. |
|
|
|
schoenherr
Tomato Guru
Germany
160 Posts |
Posted - Jun 13 2007 : 09:07:27 AM
|
@sl@sh:
item 1) knowing all the cpp's which are using a concret header file could be very useful in terms of module maintenance. Imagine the situation you have a number of hundred of modules each depending on each other. so you couldn't change a single line of code in one module whithout the danger to demolish other modules. typical huge software projects are organized in layers, and it's definitly forbidden for a low level layer to depent on higher layers. Depending on the project it's dependencies between modules are forbidden even in the same layer.
item 2) what about ignoring conditions, just show all includes. this should be still very useful |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jun 13 2007 : 09:07:51 AM
|
quote:
Originally posted by schoenherr
remembering the "goto definition" and "find reference" feature i would suspect that you already have a very good picture of the set of included header files.
I actually use these features "backwards". Open FSIW, find the class you are interested in, and when you jump to it VA opens the correct file, so suddenly you know which header file you need to include, it is the file you are sitting in 
Having said that VA does know which files you are including, and scans those for further includes, so building a "simple" include file list sounds quite doable.
Once you get into system include files most of the tree will be other system include files...
I am just wondering how useful this display, on its own, will be. I am a little wary of putting in a feature request for the display, only to have people ask for "refactoring" via this display, which quickly runs into a whole lot of special case problems. |
zen is the art of being at one with the two'ness |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jun 13 2007 : 09:15:10 AM
|
quote:
Originally posted by schoenherr
@sl@sh:
item 1) knowing all the cpp's which are using a concret header file could be very useful in terms of module maintenance.
You make a good point here, but also you have turned the question on its head.
Sitting in a cpp file and saying "please show me everything this file includes" is "easy", since you just have to scan each #include line in turn.
Sitting in a file and saying "please show me every file that includes me" is quite different, since you have to start by running a full Find in Files. This is fine for direct includes, but what about indirect includes?
I.e. you have the header "low_level_class.h"
then you get "medium_level_class.h" which includes "low_level_class.h"
then you get "high_level_class.h" which includes "medium_level_class.h"
sitting in "high_level_class.h" and finding "low_level_class.h" is "easy"
sitting in "low_level_class.h" and finding "high_level_class.h" is "hard"
I am also trying to picture how you could use the answer. If you get an include file tree with several hundred items, going 10 levels deep... how do you find anything in this? You quickly start wanting to find inside the tree, or filter it...
I have the concern this could quickly grow from a small "feature" to a rather big "feature".
Or am I reading to much into your post? |
zen is the art of being at one with the two'ness |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
|
|
schoenherr
Tomato Guru
Germany
160 Posts |
Posted - Jun 14 2007 : 12:53:02 AM
|
@feline:
no you don't read to much. thats exactly what i had in mind. i don't think it would be too hard to implement in terms of algorithm. you just have to do the "search all includes" for each source file (cpp/h) in the solution/workspace. Sure this would take some time, but personally i would spent this minute, because the alternative (which i have to do frequently) is:
1) search for statments "#include ...myfile.h"
2) copy the search result to a textfile
3) for each found header goto step 1
conisdering doing this for your low_level_class.h this would take some hours.
@sean:
looks very good and i found this tool some month ago. unfortunately we are still on VC6.0 :-(
|
|
|
|
carnitron
Junior Member
17 Posts |
Posted - Jun 14 2007 : 01:17:24 AM
|
Feline, the reason I brought up this request is simply that header files frequently get out of control on large projects. When I modify a header file that used to be "harmless", and suddenly it causes the whole universe to recompile, I want to know why! The faster I can get the answer, the better -- either a tool like VAX backtracks up through the include hierarchy, or I have to manually.
Conversely, as .cpp files change, it is quite common for people to forget (or not even try) to remove header files that are no longer necessary. It'd be nice to have a way to make it visually obvious when unused header files have been left around.
But yeah, I can see your point that this could easily grow into a larger feature. Looks like someone based a whole product around it...
Sean, I can try out IncludeManager -- that looks like what I want. Thx for the heads up.
|
|
|
|
graham.reeds
Ketchup Master
United Kingdom
51 Posts |
Posted - Jun 14 2007 : 03:59:12 AM
|
My previous place looked at IncludeManager, but while it was pretty, it didn't exactly tell you the essentials of what a tool like that should do: Refactor the includes for the minimum and possible refactor the includes where only a declaration would do.
Note: I haven't looked at it myself, but the lead did and that was just his opinion of it. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jun 14 2007 : 07:14:32 AM
|
quote:
Originally posted by graham.reeds
Refactor the includes for the minimum and possible refactor the includes where only a declaration would do.
Yes, this goes to the heart of my concern. In "simple" code this refactoring does not sound to bad, but it is quite easy to imagine cases where this is very hard to do automatically.
Simply showing the information... looking at this picture is a little concerning:
http://www.profactor.co.uk/screenshot_im.php?s=3
Firstly, how on earth do you work out what is going on when presented with a graph like that? Secondly, this sort of graph drawing is something we don't currently try to do, and I am not rushing to put in a feature request for that! |
zen is the art of being at one with the two'ness |
|
|
|
schoenherr
Tomato Guru
Germany
160 Posts |
Posted - Jun 14 2007 : 07:21:49 AM
|
@feline:
i think no one requested somthing grapically. i would be very happy with a simple (search/filter able) tree control. |
|
|
|
sl@sh
Tomato Guru
Switzerland
204 Posts |
Posted - Jun 15 2007 : 10:23:45 AM
|
@schoenherr: if your purpose is to catch #include statements that breach project-defined access restrictions then all you need is a one step reverse-include search - Find in Files handles this quite nicely. You just have to include the *.h files in your search of #include statements.
For this to be sufficient you have to explicitely define which headers are part of a package interface (and, thus, may be included from other packages). If your one step search finds one of your interface headers to include the internal header you started from, then you're in trouble - even if currently they're not (yet) being included from outside the package! If it finds any file outside your starting header's package, then you're in trouble anyway. If it finds none of these, you're safe. (the latter statement is assuming you do this check for all header files of your package)
Of course, once you find an offending file, be it .cpp or .h, you(?) will need to take a closer look at why the include is there, possibly requiring further investigation, even more reverse #include resolutions. However, you should probably delegate *that* work to the person responsible for the bad file! You need to tell him/her about this mistake anyway and I'd consider having him/her correcting this error a part of his/her education. 
I might of course misinterpret the reason for your needs.... |
|
|
|
schoenherr
Tomato Guru
Germany
160 Posts |
Posted - Jun 18 2007 : 12:43:33 AM
|
@sl@sh:
unfortunately in most projects there exists no such explicit list, but the convention all files of one directory can include all files in this directory and it's subdirectories. having now the situation of multiple files with the same name a "find in file search" can not decide which of them is included. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jun 18 2007 : 4:39:29 PM
|
I have put in a suggestion for a "simple" tree view showing this information, to see what the developers make of it:
case=7156
There is certainly a lot of interest, and I do see the appeal myself |
zen is the art of being at one with the two'ness |
|
|
|
carnitron
Junior Member
17 Posts |
Posted - Jun 20 2007 : 12:56:01 AM
|
Thanks Feline, much appreciated!
Cheers,
Peter Green |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Nov 18 2013 : 3:33:27 PM
|
case=7156 is implemented in build 2007.
Include file hierarchy viewer is a mode of the HCB in the VA View.
It can be invoked 3 ways:
- VAssistX | Tools | List include files: opens VA View and places focus in HCB
- when HCB update on position change is enabled, placing caret on a #include line updates HCB w/ includes
- when caret is within top 15 lines of editor that otherwise would leave HCB empty, then includes are listed in HCB (can be disabled via HCB context menu)
|
|
|
| |
Topic |
|
Header file dependency browser
