   locating unnecessary #include 's
  Sometimes, when code is moved between cpp files. #include <>'s that are no longer needed are left behind by misstake. It should be easy as pie for the compiler to warn on this right?Anyone know how to turn it on? (vs2005.net)(or, if not possible, know a 3rd party application that scans for this)Thanks in advance.   
  #includes are handled by the preprocesser, which knows nothing about C++ and it's types so can't tell you which includes are nessisary and which are redundant.This is basically due to the broken/stupid/simple/crude (delete as appropriate) compilation model of C++.   ;  It should be pretty easy to write a little tool which loads a cppfile, detects the includes and replaces the '#i' by '//' (to commentit out) one after the other, store to a tmp file and run the compiler on it and checks the return code..This would only work for redundant includes in cpp's..In headers it gets more complicated and you will need manualintervention (forward declarations), multiple files might dependon this hpp which might not compile anymore after the change. As faras I know there is no tool which does that - correct me if I'm wrongthough, I'd love to have a tool which could help me with that :)   ;Quote:Original post by Kitt3nIt should be pretty easy to write a little tool which loads a cppfile, detects the includes and replaces the '#i' by '//' (to commentit out) one after the other, store to a tmp file and run the compiler on it and checks the return code..Unfortunately, the results wouldn't be that great.  Consider:#include "foo.hpp"#include "bar.hpp" //depends on/includes foo.hppvoid example() { /* use foo, no longer use bar */ }Assuming we start with #1, we end up with://#include "foo.hpp"#include "bar.hpp"void example() { /* use foo, no longer use bar */ }Which compiles fine since bar.hpp internally includes foo.hpp anyways.  Commenting bar.hpp out won't work at this point, so we're left with:#include "bar.hpp"void example() { /* use foo, but not bar! */ }peter_b: It'd be easy as pie for it to warn if inclusion was symbolic.  Unforunately, it's textual, which while lending itself well to abuse by boost.preprocessor (to name an example where repeated inclusion is used) means this kind of thing really isn't that simple (unless your goal is to confuse mantinence programmers).   ;Quote:Unfortunately, the results wouldn't be that great.  Consider:True, and although it's not optimal, it still is one include less (you probably wouldn't notice a difference in compile-time because of this :)and it's definately better than going through it manually *grin*Anyway, there will be many cases where includes can really easily beremoved this way - I'm not saying that you should entirely automatethis, but at least it will give you a hint of where to start looking(rather then going through all of them by hand, which can be really a daunting task).Most effect comes anyway by using forward declarations and as littleas possible includes inside headers. It's also much more work since you have to (unfortunately) do it manually, but it's worthwhile!In my core-library I was able to reduce compile-time from 3-4 minuteswith 1.5 minutes, just by shifting includes around.   