Say I have a *.cpp/.h/.hpp* file with #include <map> in it but I do not use anything defined or referenced by map header file. I want VS to tall me a warning or something that I do not use data from file I included.
So does Visual Studio 2012 (in any of its editions) show unused includes? (answer required shall include simple - YES/NO)
These sort of answers drive me up the wall. Every other language does this. Any C++-able linker does it. It's easy:
Compile everything, producing, among other things, a symbol table for that module
Link it.
Anything that's used, but not defined, already generates an undefined external error.
Everything that's defined, but not used, should generate an extraneous external definition warning. While you're at it, group these by source file, and only generate the warning if no symbols in that module are referenced.
Either
show a warning: "Hey, man, you're not really using this thing... so... whatever, man. Cheers", or
enable a context menu options, like "remove unused includes," to clean it up.
For a static language, you have a symbol table.
When linking, you can see what items in that table are used.
You can offer an option to at least highlight everything that's NOT used.
If you really need to, build the thing, go through the above steps, and rebuild after removing potentially unused references. If it explodes, roll it back.
There are a hundred ways to solve this problem. The fact that none of the IDEs out there apparently do this is surprising.
At the very least, make it a "helpful hint" option. It's not the job of the compiler to do the programmer's job. It's the job of the IDE to do as much of the programmers job as possible, with the mutual understanding that ultimate responsibility lies with the human in the chair.
Source I used to write C compilers for a living.
There is no known way to tell if you don't use anything from an include file. It's an unsolved problem except in utterly trivial cases.
Consider the following include file:
int x;
How could you tell if x was or wasn't referenced? The compiled output that included that file might link to another object file that accesses x. The compiled object file might be linked in more than one way at more than one time.
The best way to tell if an include file is unnecessary is to comment it out or remove it entirely, and see if the code still compiles. This is a process that would be easy to automate.
Related
Say I have the below (very simple) code.
#include <iostream>
int main() {
std::cout << std::stoi("12");
}
This compiles fine on both g++ and clang; however, it fails to compile on MSVC with the following error:
error C2039: 'stoi': is not a member of 'std'
error C3861: 'stoi': identifier not found
I know that std::stoi is part of the <string> header, which presumably the two former compilers include as part of <iostream> and the latter does not. According to the C++ standard [res.on.headers]
A C++ header may include other C++ headers.
Which, to me, basically says that all three compilers are correct.
This issue arose when one of my students submitted work, which the TA marked as not compiling; I of course went and fixed it. However, I would like to prevent future incidents like this. So, is there a way to determine which header files should be included, short of compiling on three different compilers to check every time?
The only way I can think of is to ensure that for every std function call, an appropriate include exists; but if you have existing code which is thousands of lines long, this may be tedious to search through. Is there an easier/better way to ensure cross-compiler compatibility?
Example with the three compilers: https://godbolt.org/z/kJhS6U
Is there an easier/better way to ensure cross-compiler compatibility?
This is always going to be a bit of a chore if you have a huge codebase and haven't been doing this so far, but once you've gone through fixing your includes, you can stick to a simple procedure:
When you write new code that uses a standard feature, like std::stoi, plug that name into Google, go to the cppreference.com article for it, then look at the top to see which header it's defined in.
Then include that, if it's not already included. Job done!
(You could use the standard for this, but that's not as accessible.)
Do not be tempted to sack it all off in favour of cheap, unportable hacks like <bits/stdc++.h>!
tl;dr: documentation
Besides reviewing documentation and doing that manually (painful and time consuming) you can use some tools which can do that for you.
You can use ReSharper in Visual Studio which is capable to organize imports (in fact VS without ReSharper is not very usable). If include is missing it recommends to add it and if it is obsolete line with include is shown in more pale colors.
Or you can use CLion (available for all platforms) which also has this capability (in fact this is the same manufacture JetBrains).
There is also tool called include what you used, but its aim is take advantages of forward declaration, I never used that (personally - my team mate did that for our project).
I have a gigantic C++ Builder 6 solution, when I try to compile it I get the following error when the linker starts its work:
It translates to:
---------------------------
Fehler
---------------------------
Access violation at address 0660EE22 in module 'ilink32.dll'. Reading from address 00000000.
---------------------------
OK
---------------------------
Does anyone have an idea how this comes and how I can fix it?
EDIT 1
Important note, the code sometimes compiles, mostly then, when I reset the working copy and then just modify the stuff in sublime text and use C++ Builder only for compiling. Including, I don't open a single file.
EDIT 2
Some more details, the project has about 80.000.000 lines of code (according to C++ Builder). The largest file is about 70.000 lines, but you cannot say clearly, because there are a lot of
#ifdef XY
#endif
Things.
The code itself is copy-paste from an existing part and got reviewed by some coworkers. So I think it is a bug in C++ Builder, because it actually works if I just use Sublime Text or Notepad++ to edit the stuff and then use C++ Builder to build it, it works (at least sometimes).
To be honest, I myself don't think there is a real solution. But I hope someone knows this bug. According to Google, the ilink32.dll is a C++ Builder library that is linked automatically.
Maybe someone has a solution.
The ilink32 has always had a lot of bugs. There's no chance of getting anything fixed in non-current versions , so your options are:
Look for workarounds on QC
Find your own workaround
Here are some QC searches that may or may not be useful to you.
AFAIK it is not possible to use a different linker. However you can turn on (or turn off) Incremental Linking via the project options and see if that makes a difference. Incremental linking is a speed optimization, it makes no difference to the semantics of linking.
the project has about 80.000.000 lines of code (according to C++ Builder).
Well, that number counts all lines in precompiled headers for each source file so maybe it doesn't mean much.
70K LOC is large for one source file; perhaps you could try refactoring code to have smaller object files, especially if it does seem that adding to a big file does trigger the problem.
It might be possible to identify which change you are making that is triggering the bug. For example it might be increasing a particular thing past some limit (e.g. size of one object file , number of object files, size of static data, etc.)
You could delete the precompiled header files (that is vclNN.csm, vclNN.#00, vclNN.#01, etc.) that are built and saved by default in the BCB6 lib directory. Perhaps they got corrupted or could be rebuilt better. PCH management is difficult in BCB6 anyway. (I ended up defining my own "all.h" and having every source file do #include "all.h" #pragma hdrstop). Later versions of CBB XE allow PCH injection making this process a lot tidier.
Have a look at the actual link command being passed to ilink32 and see if there are any unnecessary object files or libraries in it. You could delete and re-create the project files as they can build up crud over time as a project is developed. Actually that is probably a good idea anyway.
Another possibility might be to group some of the code into static libraries .
In all cases make sure you are using good source control so you can reverse out any failed options that might make things worse
This question already has answers here:
Is there anyway to figure out what STL header file has not been included directly?
(2 answers)
Closed 9 years ago.
On Linux, what is a fast way to identify what are the necessary #include statements that I need for a C++ project?
I mean, let's say someone gives you a snippet from the web, but fails to provide the necessary #include statements. Is there potentially a way where you can run a Linux command or compiler command option and identify which functions or classes are missing, and, as a bonus, identify on the hard drive where I might have these things in a header file.
Basically you need some analyzer to parse your sources and headers and build a complete dependency graph which it spits out in the end for you to read and process further.
I'd follow john's advice on g++ and Clang for this purpose but I highly doubt they got what it takes.
What you actually can do, at least with g++, is print out a graph for already existing includes. Use the -H option to print a tree or -M to get a list.
I also refer you to this related topic: Tool to track #include dependencies
Not exactly what you want, but the tools mentioned there might be helpful.
I think Clang's "include-what-you-use" tool is what you want.
If, by necessary you mean minimal (i.e. if A includes B and B includes C then A doesn't need to include C) I don't know of a fast way.
One good approach, however, is for each cpp file to include its own header file first (after any precompiled headers.) That insures that each header file includes (directly or indirectly) all the header files it needs to define the symbols used in the header.
Also a project of reasonable size should be designed in layers such that Layer A knows about/depends on layer B which depends on layer C, etc, but lower layers never include higher layers (i.e. C never includes anything from layer A)
In that case the includes in each cpp or hpp should be in Layer order (A, B, C). If you do this it is fairly easy to check to see if any of the layer C headers can be eliminated (comment them out temporarily) because one of the includes that comes before them has already included them. This happens quite a lot and can significantly reduce the number of #includes in each file.
Having said all of that, this is a much less critical issue than it used to be because compilers are smarter. A combination of #pragma once and precompiled headers can keep build times down without requiring that you spend a lot of time optimizing includes.
The best way I know of to find undefined identifiers in a program is just to try to compile it. Depending on exactly what compiler you’re using, you might be able simply to pipe the output of GCC or Clang into grep, looking for phrases like “undeclared identifier.”
As for determining where the symbols are defined, I would recommend as a starting point looking at Ctags to parse your system headers (best managed using a Makefile) and using the resulting tags table to look up anything grep catches from GCC.
The fastest way... that's not how you should think of it.
https://stackoverflow.com/a/18544093/2112028
I wrote a lovely (I'm quite proud :P) answer there talking about how linking works (with templates) and proving it works and such, understand that.
The goal of #include directives is to create a "translation unit" where every symbol is declared (even if not defined) there's an example in my answer where I simply copy and paste the prototype into a code file, rather than use include.
You ought not worry about the "fastest" way if you use something called "Header guards" (these are mentioned briefly right at the bottom, but this isn't sufficient detail) they go like this:
#ifndef __WHATEVER_H
#define __WHATEVER_H
/*Your code here*/
#endif
So now you can include "whatever.h" AS MANY times as you like. the first time IN THE TRANSLATION UNIT, will define __WHATEVER_H, so the next file that includes it (however many includes deep from the file being compiled) will be empty. as everything between the #ifndef and #endif will be gone.
Hope this helps.
Also if you have unnecessary inputs, use -Wextra and -Wall, GCC will tell you about unused functions, typedefs and so forth. you can use the pragma error push and pop things to control this. For example wxWidget's header files may contain a lot of unused things, so you push the warnings onto the stack, remove the unused warning flags, include the file, pop the warnings stack (turning them back on), less you get thousands of lines of warnings.
I'm somewhat new to C/C++, and I find myself spending exorbitant amounts of time searching through header files (one innocent include might actually bring dozens more header files with it). Even helpful IDEs like Visual Studio aren't always helpful; sometimes when I try to go to the definition of a function, it prompts me to choose from several--the very thing I was trying to avoid.
So...in a very large project with thousands of header files and many occurrences of functions that share the same name and parameters, what's the best way to determine, without question, which specific function is being called?
Try adding /showIncludes to the compiler command line (In the project settings, Configuration Properties, C/C++, Command Line). This outputs all the headers used in a given .cpp file compilation. This is not a fast way, but it is a sure way.
When Intellisense isn't working, I recommend Find in Files. It is easier to track down the definition in the header this way. I find I can usually tell which is the relevant declaration.
Keep in mind that you cannot find the source in the header, unless you are dealing with templates or inlined functions. So there is generally no reason to attempt to discriminate which declaration(s) are being applied. If the definition exists in a SOURCE file (.c,.cpp), then there can only be one function of that name and signature for it to compile. It is generally better to google the function name if it is a published API from Microsoft or another source.
Tools such as Visual Assist for Visual Studio improve the ability to locate such definitions, as well.
Also, you can massage Intellisense into working better. Try deleting the Intellisense Database and having it be rebuilt. You can see where it has trouble by the "errors" it shows in the error view. Often you need to improve the includes directories, especially if this is a makefile project. If it grays out code that shouldn't be grayed out, some preprocessor symbol is wrong. Maintaining the Intellisense is often worth it because it's great when it works.
Tools such as Visual Assist for Visual Studio have their own, often improved intellisense-like method of finding definitions.
Admittedly, I'm still new to C++ (and programming in general) as well. But, I think that the Visual Studio feature you describe in your question is the most help you'll get. It will narrow things down a little for you, but you'll still have to do some good ole sleuthing.
Ask the compiler. No, really! It's the only way to be sure.
Try using Microsoft visual studio 2005. You can easily jump onto the function definition, Function declaration also you can see the Function call and callers graph as well.
I often find that the headers section of a file get larger and larger all the time but it never gets smaller. Throughout the life of a source file classes may have moved and been refactored and it's very possible that there are quite a few #includes that don't need to be there and anymore. Leaving them there only prolong the compile time and adds unnecessary compilation dependencies. Trying to figure out which are still needed can be quite tedious.
Is there some kind of tool that can detect superfluous #include directives and suggest which ones I can safely remove?
Does lint do this maybe?
Google's cppclean (links to: download, documentation) can find several categories of C++ problems, and it can now find superfluous #includes.
There's also a Clang-based tool, include-what-you-use, that can do this. include-what-you-use can even suggest forward declarations (so you don't have to #include so much) and optionally clean up your #includes for you.
Current versions of Eclipse CDT also have this functionality built in: going under the Source menu and clicking Organize Includes will alphabetize your #include's, add any headers that Eclipse thinks you're using without directly including them, and comments out any headers that it doesn't think you need. This feature isn't 100% reliable, however.
Also check out include-what-you-use, which solves a similar problem.
It's not automatic, but doxygen will produce dependency diagrams for #included files. You will have to go through them visually, but they can be very useful for getting a picture of what is using what.
The problem with detecting superfluous includes is that it can't be just a type dependency checker. A superfluous include is a file which provides nothing of value to the compilation and does not alter another item which other files depend. There are many ways a header file can alter a compile, say by defining a constant, redefining and/or deleting a used macro, adding a namespace which alters the lookup of a name some way down the line. In order to detect items like the namespace you need much more than a preprocessor, you in fact almost need a full compiler.
Lint is more of a style checker and certainly won't have this full capability.
I think you'll find the only way to detect a superfluous include is to remove, compile and run suites.
I thought that PCLint would do this, but it has been a few years since I've looked at it. You might check it out.
I looked at this blog and the author talked a bit about configuring PCLint to find unused includes. Might be worth a look.
The CScout refactoring browser can detect superfluous include directives in C (unfortunately not C++) code. You can find a description of how it works in this journal article.
Sorry to (re-)post here, people often don't expand comments.
Check my comment to crashmstr, FlexeLint / PC-Lint will do this for you. Informational message 766. Section 11.8.1 of my manual (version 8.0) discusses this.
Also, and this is important, keep iterating until the message goes away. In other words, after removing unused headers, re-run lint, more header files might have become "unneeded" once you remove some unneeded headers. (That might sound silly, read it slowly & parse it, it makes sense.)
I've never found a full-fledged tool that accomplishes what you're asking. The closest thing I've used is IncludeManager, which graphs your header inclusion tree so you can visually spot things like headers included in only one file and circular header inclusions.
You can write a quick script that erases a single #include directive, compiles the projects, and logs the name in the #include and the file it was removed from in the case that no compilation errors occurred.
Let it run during the night, and the next day you will have a 100% correct list of include files you can remove.
Sometimes brute-force just works :-)
edit: and sometimes it doesn't :-). Here's a bit of information from the comments:
Sometimes you can remove two header files separately, but not both together. A solution is to remove the header files during the run and not bring them back. This will find a list of files you can safely remove, although there might a solution with more files to remove which this algorithm won't find. (it's a greedy search over the space of include files to remove. It will only find a local maximum)
There may be subtle changes in behavior if you have some macros redefined differently depending on some #ifdefs. I think these are very rare cases, and the Unit Tests which are part of the build should catch these changes.
I've tried using Flexelint (the unix version of PC-Lint) and had somewhat mixed results. This is likely because I'm working on a very large and knotty code base. I recommend carefully examining each file that is reported as unused.
The main worry is false positives. Multiple includes of the same header are reported as an unneeded header. This is bad since Flexelint does not tell you what line the header is included on or where it was included before.
One of the ways automated tools can get this wrong:
In A.hpp:
class A {
// ...
};
In B.hpp:
#include "A.hpp
class B {
public:
A foo;
};
In C.cpp:
#include "C.hpp"
#include "B.hpp" // <-- Unneeded, but lint reports it as needed
#include "A.hpp" // <-- Needed, but lint reports it as unneeded
If you blindly follow the messages from Flexelint you'll muck up your #include dependencies. There are more pathological cases, but basically you're going to need to inspect the headers yourself for best results.
I highly recommend this article on Physical Structure and C++ from the blog Games from within. They recommend a comprehensive approach to cleaning up the #include mess:
Guidelines
Here’s a distilled set of guidelines from Lakos’ book that minimize the number of physical dependencies between files. I’ve been using them for years and I’ve always been really happy with the results.
Every cpp file includes its own header file first. [snip]
A header file must include all the header files necessary to parse it. [snip]
A header file should have the bare minimum number of header files necessary to parse it. [snip]
If you are using Eclipse CDT you can try http://includator.com which is free for beta testers (at the time of this writing) and automatically removes superfluous #includes or adds missing ones. For those users who have FlexeLint or PC-Lint and are using Elicpse CDT, http://linticator.com might be an option (also free for beta test). While it uses Lint's analysis, it provides quick-fixes for automatically remove the superfluous #include statements.
This article explains a technique of #include removing by using the parsing of Doxygen. That's just a perl script, so it's quite easy to use.
CLion, the C/C++ IDE from JetBrains, detects redundant includes out-of-the-box. These are grayed-out in the editor, but there are also functions to optimise includes in the current file or whole project.
I've found that you pay for this functionality though; CLion takes a while to scan and analyse your project when first loaded.
Here is a simple brute force way of identifying superfluous header includes. It's not perfect but eliminates the "obvious" unnecessary includes. Getting rid of these goes a long way in cleaning up the code.
The scripts can be accessed directly on GitHub.
Maybe a little late, but I once found a WebKit perl script that did just what you wanted. It'll need some adapting I believe (I'm not well versed in perl), but it should do the trick:
http://trac.webkit.org/browser/branches/old/safari-3-2-branch/WebKitTools/Scripts/find-extra-includes
(this is an old branch because trunk doesn't have the file anymore)
There is a free tool Include File Dependencies Watcher which can be integrated in the visual studio. It shows superfluous #includes in red.
There's two types of superfluous #include files:
A header file actually not needed by
the module(.c, .cpp) at all
A header file is need by the module
but being included more than once, directly, or indirectly.
There's 2 ways in my experience that works well to detecting it:
gcc -H or cl.exe /showincludes (resolve problem 2)
In real world,
you can export CFLAGS=-H before make,
if all the Makefile's not override
CFLAGS options. Or as I used, you
can create a cc/g++ wrapper to add -H
options forcibly to each invoke of
$(CC) and $(CXX). and prepend the
wrapper's directory to $PATH
variable, then your make will all
uses you wrapper command instead. Of
course your wrapper should invoke the
real gcc compiler. This tricks
need to change if your Makefile uses
gcc directly. instead of $(CC) or
$(CXX) or by implied rules.
You can also compile a single file by tweaking with the command line. But if you want to clean headers for the whole project. You can capture all the output by:
make clean
make 2>&1 | tee result.txt
PC-Lint/FlexeLint(resolve problem
both 1 and 2)
make sure add the +e766 options, this warning is about:
unused header files.
pclint/flint -vf ...
This will cause pclint output included header files, nested header files will be indented appropriately.
clangd is doing that for you now. Possibly clang-tidy will soon be able to do that as well.
To end this discussion: the c++ preprocessor is turing complete. It is a semantic property, whether an include is superfluous. Hence, it follows from Rice's theorem that it is undecidable whether an include is superfluous or not. There CAN'T be a program, that (always correctly) detects whether an include is superfluous.