Author |
Topic |
|
peterchen
Tomato Guru
126 Posts |
Posted - Jul 16 2009 : 10:07:21 AM
|
Suggestion for a (major?) feature:
From the informaiton you have, determine automatically which #includes in a project are actually necessary.
Managing large C++ projects has two related problems: First, exploring the actual #include hierarchy to find existing dependencies, cycles etc.
Second, reducing these dependencies to reduce build time - esp. for incremental builds - and avoid redundancy, and inclusion of unecessary code. Over time, functionality moves to other headers or is replaced, and existing #includes become stale. Cleaning up these is virtually impossible without extensive time testing a rebuild, but not taking care of this and "playing it safe" to avoid breaking builds creates artificial dependencies that bog down builds.
As I was recommending a tool for the former, I wanted to add that I don't know any tool for the latter - nor that I know any way of implementing it, short of understanding all symbols and where they come from.
This is when I thought of you guys: You already have that information!
What I envision in my head is this: A mode or method or setting to flag existing #includes as "directly necessary" (a symbol is required and needs to be made made available through this include), "necessary but available indirectly" - i.e. the symbol is required but some other #include already provides that - or "unnecessary".
Additionally, some hint at the "weight" of includes would be nice, i.e. which includes have most impact, provide the most symbols etc.
Now, I can think of a good dozen of problems that make this task non-trivial, and a handfull of cases where you can't possibly know a file is needed, but still I think you can provide a lot of additional value compared to standard include hierarchy finder tools.
Your advantage over others is that besides the current hierarchy of files you also know where a symbol is defined, and where it is used.
What do you think? |
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jul 16 2009 : 2:57:39 PM
|
I am not sure what to say to all of this. Finding and working out which headers are no longer required comes up every now and then, but at least when working in .h files is difficult, since you might break code that includes the file you are working in. So you have to scan down as well as up.
Of course you then have to think about the people who get clever and #include a .cpp file. I have seen it done, but only occasionally, thankfully
As soon as you get into the whole idea of the "weight" of a header file, you really need to start asking the compiler these questions, since "size" of a header file is not always what matters.
We probably won't think to much about this any time soon, since we are currently focussing quite a lot of attention on VS2010. |
zen is the art of being at one with the two'ness |
|
|
peterchen
Tomato Guru
126 Posts |
Posted - Aug 06 2009 : 06:04:41 AM
|
VS 2010 is definitely more important.
It's jsut an idea for brainstorming (in case you guys sit around and wonder what you could do next ;)) |
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Aug 06 2009 : 3:45:58 PM
|
Ideas are always welcome Most of our new features start out as ideas from our customers after all |
zen is the art of being at one with the two'ness |
|
|
|
Topic |
|
|
|