Whole Tomato Software Forums

Whole Tomato Software Forums

All Forums

Visual Assist

Feature Requests

Cleaning C++ includes

You must be registered to post a reply.
Click here to register.

Screensize:

UserName:

Password:

Format:

Message:

Forum code is on.
Html is off.

Check to include your profile signature.
Check to subscribe to this topic.

T O P I C R E V I E W
patricks	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
5 L A T E S T R E P L I E S (Newest First)
sean	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)
accord	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.
peterchen	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.
patricks	Posted - Jun 03 2010 : 07:22:24 AM Fair enough, thanks for the prompt reply nonetheless!
accord	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.

Snitz Forums 2000