| Author |
 Topic  |
|
|
patricks
New Member
2 Posts |
 Posted - Jun 02 2010 : 11:31:49 AM
|
Hi there,
I was wondering if it is currently possible, or will be possible in future editions, to automate cleaning up of unnecessary C++ include directives? These are often hard to manage, especially on large codebases...
Cheers,
Pat |
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Jun 02 2010 : 1:43:34 PM
|
We have a feature request for this:
case=32032
but don't hold your breath: this is not something we try to do in the near future: Consider the following code:
foo.h
#ifdef WIN32
#include "bar.h"
#include <string>
#elif UNIX
#include "../bar.h"
#include "homegrown_string.h>
#else
#include <string.h>
#endif
suddenly there is no single answer to the question, since the code is targeting several OS's, and has different rules for each OS.
C++ is quite complex so it is not feasible to analize everything fast and still reliably. In addition, in C++ the problem is often that people may include headers to other headers which results in a very complex include hierarchy that is not possible to simplify without modifying some code. |
 |
|
|
patricks
New Member
2 Posts |
Posted - Jun 03 2010 : 07:22:24 AM
|
| Fair enough, thanks for the prompt reply nonetheless! |
|
|
|
peterchen
Tomato Guru
126 Posts |
Posted - Jun 22 2010 : 04:11:57 AM
|
Just to throw in some thoughts for whoever wants to discuss that further.
I've pondered this a few times, It looks like a huge amount of work, and would benefit largely us large project C++ guys, not exactly a growing target Thus I fully agree with the hesitation to tackle that. OTOH incremental build times *are* a large cost factor that at some point can't be fixed with faster machines anymore.
From my experience with large projects, it's definitely hard just to keep the code working correctly. However, as I blurted before, VA "has" a good chunk of the information required to identify stale items (not necessarily in a suitable format, but it's there).
ATM I figured out it's not even easy to say which information would help with a manual cleanup. Maybe for each symbol in a file the include stack and whether a forward decl would be sufficient. This together with some "change cost" (roughly - how often a (header) file gets hit during a build, and how many files depend on that) might help.
|
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Jun 22 2010 : 2:20:25 PM
|
Some times ago I was dealing with a larger code base and we decided to reduce the compile time drastically. Since most waste was doing in header files I end up writing a little tool which read all files in the project, then did an analysis: which header files includes the most other files *recursively*. So we could cut out the files with most compiler-time impact. (Anyway, my other conclusion was to use #pragma once where it is possible. Compiler won't analyze the file again, unlike with include guards)
We are considering a feature to show "Include File Hierarchy", maybe also for symbols:
case=7156
but I don't understand your remark about forward declaration. |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Nov 18 2013 : 3:34:06 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 |
|
Cleaning C++ includes
