In general, I occasionally have a chain of nested macros with a few preprocessor conditional elements in their definitions. These can be painful to debug since it's hard to directly see the actual code being executed.
A while ago I vaguely remember finding a compiler (gcc) flag to expand them, but I had trouble getting this to work in practice.
gcc -E will output the preprocessed source to stdout.
For MSVC users, you can right-click on the file/project, view the settings and change the file properties to output preprocessed source (which typically in the obj directory).
This might not be applicable in your situation, but macros really do hamper debugging and often are overused and avoidable.
Can you replace them with inline functions or otherwise get rid of them all together?
You should probably start moving away form Macros and start using inline and templates.
Macros are an old tool, the right tool sometimes. As a last resort remember printf is your friend (and actually printf isn't that bad a friend when your doing multithreaded stuff)
Debug the dissasembly with the symbols loaded.
gcc -save-temps
will write out a .i (or .ii file for C++) which is the output of the C preprocessor, before it gets handed to the compiler. This can often be enlightening.
GCC and compatible compilers use the -E option to output the preprocessed source to standard out.
gcc -E foo.cpp
Sun Studio also supports this flag:
CC -E foo.cpp
But even better is -xdumpmacros. You can find more information in Suns' docs.
Related
I had to customize some projects which have been written for some other purpose but some core functionality is same for my project and works as it is. But There are lots of variables, macros,functions etc.. which are not useful for my current context and they are just making the code very uneasy to read and unnecessarily big.
So I started removing the variables macros functions etc.. by using "Find References" and "Show Call Graph" in Netbeans. I'm using netbeans remote development tools for c/c++.
But its cumbersome. So Is there any tool to do this clean up??
From what I know there is currently no tool that does all the things you have mentioned, however there is one that helps in cleaning up the unused include headers: include-what-you-use
"Include what you use" means this: for every symbol (type, function
variable, or macro) that you use in foo.cc, either foo.cc or foo.h
should #include a .h file that exports the declaration of that symbol.
The include-what-you-use tool is a program that can be built with the
clang libraries in order to analyze #includes of source files to find
include-what-you-use violations, and suggest fixes for them.
The main goal of include-what-you-use is to remove superfluous #includes. It does this both by figuring out what #includes are not actually needed for this file (for both .cc and .h files), and
replacing #includes with forward-declares when possible.
One might expect that the Clang static analyzer would do this, but from what I see the availalbe checks do not offer such things.
This might be a good time for someone to suggest a feature request to the analyzer or create a separate tool using LibTooling on a similar par with the tools described at Clang Tools
In the meantime, I'd suggest you enable -Wall and -Wextra compiler flags, which will trigger the following warnings (among others)(see the GCC docs below):
-Wunused-function
-Wunused-label
-Wunused-value
-Wunused-variable
-Wunused-parameter
-Wunused-but-set-parameter
If for some reason you don't want to do that, you could just add -Wunused which will enable only the above -Wunused options combined, without the other flags that -Wall or -Wextra adds.
But in order to get a warning about an unused function parameter, you
must either specify -Wextra -Wunused (note that -Wall implies
-Wunused), or separately specify -Wunused-parameter.
Of course, this means that you have to do the cleanup manually
If you want to be extra pedantic you might as well convert all the warnings into errors by adding the -pedantic-errors flag
For more details read the GCC Warnings Options documentation.
I've sometimes used the method of marking a big block of code as "not used" by adding
#if 0
... lots of code
#endif
You can then compile the code and see what goes wrong. Analyze the "undeclared varibale X" errors you get and reinstate the bits necessary for that. You can do this by either "cutting up" the #if 0 block (adding an #endif, then a new #if 0 a bit further down), or by moving the pieces you need out of the current block.
For example, if you have a block of global variables or macros, just put #if 0 around all of them, and see which ones are actually used. [Although macros can be a little more tricky if they are used in #ifdef and such].
I'd be surprised if there isn't a tool out there, but at the same time, you still have to do the cutting job, and once you have a large chunk of code in #if 0 ... #endif, it's pretty easy to cut it out.
Many static code analysis tools provide the information you want. Wikipedia has a list.
We have successfully used such a tool (with some custom changes) to remove includes and speed up compile time.
A colleague recently revealed to me that a single source file of ours includes over 3,400 headers during compile time. We have over 1,000 translation units that get compiled in a build, resulting in a huge performance penalty over headers that surely aren't all used.
Are there any static analysis tools that would be able to shed light on the trees in such a forest, specifically giving us the ability to decide which ones we should work on paring out?
UPDATE
Found some interesting information on the cost of including a header file (and the types of include guards to optimize its inclusion) here, originating from this question.
The output of gcc -w -H <file> might be useful (If you parse it and put some counts in) the -w is there to suppress all warnings, which might be awkward to deal with.
From the gcc docs:
-H
Print the name of each header file used, in addition to other normal activities. Each name is indented to show how deep in the
#include stack it is. Precompiled header files are also printed,
even if they are found to be invalid; an invalid precompiled header
file is printed with ...x and a valid one with ...!.
The output looks like this:
. /usr/include/unistd.h
.. /usr/include/features.h
... /usr/include/bits/predefs.h
... /usr/include/sys/cdefs.h
.... /usr/include/bits/wordsize.h
... /usr/include/gnu/stubs.h
.... /usr/include/bits/wordsize.h
.... /usr/include/gnu/stubs-64.h
.. /usr/include/bits/posix_opt.h
.. /usr/include/bits/environments.h
... /usr/include/bits/wordsize.h
.. /usr/include/bits/types.h
... /usr/include/bits/wordsize.h
... /usr/include/bits/typesizes.h
.. /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include/stddef.h
.. /usr/include/bits/confname.h
.. /usr/include/getopt.h
. /usr/include/stdio.h
.. /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include/stddef.h
.. /usr/include/libio.h
... /usr/include/_G_config.h
.... /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include/stddef.h
.... /usr/include/wchar.h
... /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include/stdarg.h
.. /usr/include/bits/stdio_lim.h
.. /usr/include/bits/sys_errlist.h
Multiple include guards may be useful for:
/usr/include/bits/confname.h
/usr/include/bits/environments.h
/usr/include/bits/predefs.h
/usr/include/bits/stdio_lim.h
/usr/include/bits/sys_errlist.h
/usr/include/bits/typesizes.h
/usr/include/gnu/stubs-64.h
/usr/include/gnu/stubs.h
/usr/include/wchar.h
If you are using gcc/g++, the -M or -MM option will output a line with the information you seek. (The former will include system headers while the latter will not. There are other variants; see the manual.)
$ gcc -M -c foo.c
foo.o: foo.c /usr/include/stdint.h /usr/include/features.h \
/usr/include/sys/cdefs.h /usr/include/bits/wordsize.h \
/usr/include/gnu/stubs.h /usr/include/gnu/stubs-64.h \
/usr/include/bits/wchar.h
You would need to remove the foo.o: foo.c at the beginning, but the rest is a list of all headers that the file depends on, so it would not be too hard to write a script to gather these and summarize them.
Of course this suggestion is only useful on Unix and only if nobody else has a better idea. :-)
a few things-
use "preprocess only" to look at your preprocessor output. gcc -E option, other compilers have the function too
use precompiled headers.
gcc has -verbose and --trace options which also display the full include tree, MSVC has the /showIncludes option found under Advanced C++ property page
Also, Displaying the #include hierarchy for a C++ file in Visual Studio
"Large Scale C++ Software Design" by John Lakos had tools that extracted the compile-time dependencies among source files.
Unfortunately, their repository on Addison-Wesley's site is gone (along with AW's site itself), but I found a tarball here:
http://prdownloads.sourceforge.net/introspector/LSC-rpkg-0.1.tgz?download
I found it useful several jobs ago, and it has the virtue of being free.
BTW, if you haven't read Lakos's book, it sounds like your project would benefit. (The current edition is a bit dated, but I hear that Lakos has another book coming out in 2012.)
GCC has a -M flag that will output a list of dependencies for a given source file. You could use that information to figure out which of your files have the most dependencies, which files are most depended on, etc.
Check out the man page for more information. There are several variants of -M.
Personally I don't know if there is a tool that will say "Remove this file". It's really a complex matter that depends on a lot of things. Looking at a tree of include statements is surely going to drive you nuts.... It would drive me crazy, as well as ruin my eyes. There are better ways to do things to reduce your compile times.
De-inline your class methods.
After deinlining them, re-examine your include statements and attempt to remove them. Usually helpful to delete them, and start over.
Prefer to use forward declarations are much as possible. If you de-inline methods in your header files you can do this alot.
Break up large header files into smaller files. If a class in a file is used more often than most, then put it in a header file all by itself.
1000 translational units is not very much actually. We have between 10-20 thousand. :)
Get Incredibuild if your compile times are still too long.
I heard there are some tools do it, but I don't use them.
I created some tool https://sourceforge.net/p/headerfinder may be this is useful. Unfortunately it is "HOME MADE" tool with following issues,
Developed in Vb.Net
Source code need to compiled
Very slow and consumes memory.
No help available.
GCC Has a flag (-save-temps) with which you can save intermediate files. This includes .ii files, which are the results of the preprocessor (so before compilation). You can write a script to parse this and determine the weight/cost/size of what is included, as well as the dependency tree.
I wrote a Python script to do just this (publicly available here: https://gitlab.com/p_b_omta/gcc-include-analyzer).
Sometimes I run across quite complicated macros and I would like to view what they will expand to given the parameters (there are string concatenations in there as well). Is there by any chance a program out there that will expand the macros?
I am aware of the compiler flag -E but what about a single file (or preferably a single macro?)
Eclipse will expand macros if you mouse over them. For macros which include other macros, Eclipse can even step through the macro expansions one step at a time.
(You can use Eclipse for this even if you normally use another IDE.)
A few options are:
In GCC:
gcc -E filename.c
Using computers precompiler:
cpp filename.c
In visual Studio:
Right-click on the file on the Solution Explorer, goto Properties. Under Configuration Properties->C/C++->Preprocessor & "Generate Preprocessed File"
The C and C++ preprocessor is called cpp on most systems - you can use it directly:
cpp somefile.c
will preprocess somefile.c, expanding macros and write the results to standard output. If you are using the Microsoft compiler:
cl -E somefile.c
will do the same, assuming you have the compiler on your PATH.
Netbeans IDE allows you to view what a macro expands to by holding Ctrl+Alt and hovering/clicking a macro.
My code is linking against several other libraries that are also developed at my company, one of these libraries is redefining several values from errno.h, I would like to be able to fix this, however I am having trouble finding the exact file that is redefining these values, I am want to know if there is a way to make the compiler tell me when a file has defined a particular value.
You can probably do it by adding -include errno.h to the command line that builds the library in question. Here's a quick example. I have a C program called "file.c":
#define ESRCH 8
That's it - then I compile with:
cc -c -include errno.h file.c
And presto, a compiler warning:
file.c:1:1: warning: "ESRCH" redefined
In file included from /usr/include/errno.h:23,
from <command-line>:0:
/usr/include/sys/errno.h:84:1: warning: this is the location of the previous definition
That will tell you where your bad definitions are.
Have you tried searching with grep?
If you don't want to search through all your headers for the particular #define, you could use
#undef YOUR_MANIFEST_CONSTANT
after each #include in your source module and then start removing them from the bottom up and see where your definitions come from.
Also, your compiler may tell you that a #define has been redefined. Turn all your warnings on.
With GCC I did something similar with:
g++ input.cc -dD -E > cpp.out
-dD tells cpp to print all defines where they were defined. And in the cpp output there are also markers for the include file names and the line numbers.
It is possible that some environments, I'm thinking IDE's here, have configuration options tied into the "project settings" rather than using a configuration header. If you work with a lot of other developers in a place where this behavior is NOT frowned on then you might also check your tool settings.
Most compilers will tell you where the problem is, you have to look and think about what the diagnostic notification is telling you.
Short of that, grep/findstr on *nix/Windows is your friend.
If that yields nothing then check for tool settings in your build system.
Some IDE's will jump to the correct location if you right click on the usage and select 'go to definition'.
Another option if you're really stuck is a command line option on the compiler. Most compilers have an option to output the assembler they generate when compiling C++ code.
You can view this assembler (which has comments letting you know the relative line number in the C++ source file). You don't have to understand the assembler but you can see what value was used and what files and definitions were included when the compiler ran. Check your compiler's documentation for the exact option to use
I learned that compiler will expand macros while compiling. Templates are also expanded at the compile time. Is there any way to see this expanded code? I am compiling using Visual Studio 2008.
any thoughts?
The VC++ compiler (cl.exe) supports a few command line switches for this:
/E preprocess to stdout
/P preprocess to file
/EP preproscess to stdout with no #lines
Additional command-line switches can be added in your project properties. In my version (VC2005), Configuration Options -> C/C++ -> Command Line -> Additional Options
The compiler doesn't actually do any of the macro expansion. That is the task of the pre-processor. It all appears as one step, but the compiler actually forks out to a separate pre-processor tasks and traps the output for you.
Templates are not "expanded" at compile time. They are instantiated on use during compile. The difference is that the compiler immediately generates object code for the template; there's no intermediate source code that comes out. You can't look at the instantiated template code as source, it's dumped out as assembly when it's needed.
If you have GCC you can also call the pre-processor directly using 'cpp' with the right arguments (mostly include paths and command line macro definitions). Others have answered for MSVC.
Note that /E in VC++ only expands preprocessor statements (that is, #include, #ifdef, #define etc.)
I am not aware of any modern compiler that allows to expand templates.
To emit the preprocessed code, call cpp directly of use the -E option in gcc and related compilers; I'm sure other compilers or suites have similar things (indeed as per the other answer it's /E or /P in VC++).
Not sure about outputting instantiated templates. That's much harder to do, I think, since it's actually part of compilation rather than preprocessing (at least in modern compilers, since the original cfront version which was a c++-to-c translator, if I recall correctly).
It's easy to add an option to compilers to show the output after macro substitution. That's defined as a simple text substitution option anyway. Many compilers implement this as a separate stage, sometimes even handled as a separate tool. In any case, the result of the macro substitution is a collection of Translation Units in text form.
Templates, on the other hand, are compiled. There are multiple stages to this. Names are resolved twice, for instance. In either stage, the compiler would store the result of the name lookup. That's a table entry. How would you show that in text form? There's no trivial C++ expression for that.