I am integrating Guideline Support Library Checkers into a project of mine.
Microsoft.CppCoreCheck
Microsoft.Gsl
When I run it I get a bunch of errors from included libraries like standard libraries, glm, boost, etc.
One concrete example is SDL.h where I get warnings in sdl_stdinc.h.
I made sure that I include SDL only via one header under my control:
ExtSDL.hpp
#pragma once
#pragma warning(disable: 4710)
#pragma warning(push, 0)
#include <SDL.h>
#pragma warning(pop)
I can not find information on how to exclude this library from the static code analysis.
There are multiple ways to suppress CppCoreCheck warnings:
you can suppress CppCoreChecks either using
[[gsl::suppress(chapter)]] attribute, where chapter comes from C++
Core Guidelines, for example, con.4. Please also look at MS docs for information.
you can use #pragma warning to suppress warnings individually or in bulk, as mentioend above.
you can suppress all warnings for "not your code" using CAExcludePath.
The most practical approach I've found so far is to build up #defines like
#define SDL_WARNINGS 4710 26135
and then #include other people's dirty code thusly
#pragma warning(push)
#pragma warning(disable: SDL_WARNINGS)
#include <SDL.h>
#pragma warning(pop)
That will silence warnings for gsl checkers, based on their associated warning codes e.g C26135 above. It silences the compiler exactly where you want it to keep quiet. Note the warning disablement is local to the push/pop scope.
This sort of approach allows one to compile /Wall /WX even if you turn additional checking on, including gsl. Critically it works even when you have dependencies on other people's headers which aren't warning clean. Sadly this includes every C and C++ standard library implementation I've seen plus Boost, LLVM, the Windows SDK etc. etc. i.e. basically everything. Additionally it protects you from evil headers which alter warning pragmas (some standard library implementations used to do this and may still...) This approach allows you to lift your own code to a higher level of cleanliness and quality than the dross you are dependent upon.
One of the good things about the Microsoft C++ Core Check stuff is the way they've tied it into the usual mechanisms used for warnings, so this approach works uniformly for regular warnings and checkers in extra rulesets. Thank goodness they did something like this: some of the gsl checkers are rather questionable and incompatible with many extant coding styles i.e. turn gsl on for code which #includes big standard vendor library and you rapidly need to construct a long list of warning codes to disable before you can dial the noise down so you can focus on your own code. Of course you can globally #pragma warning(disable: GSL_CHECKERS_YOU_DONT_LIKE) for your own code, so you can focus on the aspects of it you find useful.
Alternatively you can pick the rules to apply by selecting rulesets to use and/or making a custom one. That's presumably going to minimise your build times which aren't as quick with Code Analysis enabled.
It would be nice to have a more direct answer to your question which essentially made the dirty headers build quickly because you could disable checkers for "other people's stuff". It's an obvious feature request but I'm not aware of it being supported. Presumably it would be pretty trivial to implement e.g. only run the checkers on source code found in a specified set of directories, so if a #include steps outside that zone the checkers are automatically disabled. Is anyone at Microsoft reading this?
I'm developing a game engine for Sega Dreamcast and Windows. I have implemented my own library for the Dreamcast hardware, which pretty much does the same thing as OpenGL for PC. Now, I want to merge the two builds into one project, so I don't need to dev to different project doing the exact same high level stuff.
I know you can add a preprocessing line like this: #define DREAMCAST, and then the Dreamcast headers will be included and the appropriate low level function will be called instead of OpenGL. This has been done before, but I don't know how to make that possible.
This has really nothing to do with Dreamcast, it could be Mac, Linux or whatever. I have different compilers for each platform. So when #define DREAMCAST, I want the G++ KOS compiler to include the Dreamcast-specific headers and classes. If #define DREAMCAST is not present, I want MingGW to include the Windows OpenGL headers and classes.
How can I do this?
For the initial problem of including different versions depending on a predefined symbol, a simple solution is available:
#if defined(DREAMCAST)
#include <my_dreamcast_header>
#else
#include <opengl_header>
#endif
This functionality should be available on just about any C or C++ compiler - and it definitely is on MinGW. You still need to invoke the correct compiler yourself of course, as there is no way to change the compiler once compilation starts.
I looked at a sample code to create a log system on my server... And I found this
#if DEBUG
printf("something here");
#endif
I know what it does. It prtins something only if DEBUG has been defiend. But where is DEBUG defined? I looked at the all the header files but I could't find DEBUG..
Also, Could you please provide me a good example or tutorial about designing logging system?
Thanks in advance..
Do not use the DEBUG macro it is not defined by C++ standard. C++ Standard defines NDEBUG (No DEBUG), which is used for the standard assert macro and your logging code would go hand in hand with it. DEBUG is compiler dependent. Therefore NDEBUG is ensured by standard to be properly set. Applying it to your example use:
#ifndef NDEBUG
printf("something here");
#endif
But my opinion is: you should not design a logging library around the NDEBUG/DEBUG pair. Logging lib should always be there, just to allow you trace the application's behavior without the need of code recompilation, which in turn involves new deployment of your code and possibility to postpone the bug prone behavior. The following DDJ article by Petru Marginean about design of logging libraries describes how to ensure that fact in a very efficient manner in C++:
Part 1: http://drdobbs.com/cpp/201804215
Part 2: http://drdobbs.com/cpp/221900468
Regarding the logging library take a look at the Boost Logging library at:
http://boost-log.sourceforge.net/libs/log/doc/html/index.html
I was downvoted because NDEBUG is said not to be set without explicit definition of it in the command line. I agree with that fact, but on the other hand here I understand this question so, that compilation in debug mode, should also produce logging output. This fact is going to be better enforced when bundling the behavior to NDEBUG presence.
Compilers, at least those I know of, have an option to define preprossessor macros from "the outside" of compiled files.
For example, to define DEBUG with a microsoft compiler, you'd go with something like
cl -DDEBUG file.cpp ...
Easy way to detect position of first definition, you add #define .
#include "someone.h"
#define DEBUG "dummy" // add this
#if DEBUG
printf("something here");
#endif
You'll get
foo.c:2:0: warning: "DEBUG" redefined
<command-line>:0:0: note: this is the location of the previous definition
Or
foo.c:30:0: warning: "DEBUG" redefined
someone.h.c:2:0: note: this is the location of the previous definition
Another answer, try to use ctags. run ctasg -R on the top of the project directory, run vim /path/to/your/code.c. move cursor to DEBUG, then type CTRL-].
This way, you may find several definitions. You can find all with :tselect on the DEBUG.
In Visual Studio, you can set Preprocessor Symbols in Project Properties. As for logging system, take a look at log4cpp
Is there a way for the preprocessor to detect if the code in current
translation unit uses(or is creating) precompiled headers?
---
The actual problem I'm facing right now is that I'm on a project that is
abusing PCH by precompiling virtually all header files. That means there is none of
the clear dependency management you can get from #includes and the compile times is awful.
Practically every change will trigger a full rebuild.
The application is way to big to just fix it in one go, and some of the old guys refuses
to belive that precompiling everyting is bad in any way. I will have to prove it first.
So I must do it step by step and make sure my changes does not affect
code that is compiled the old PCH way.
My plan is to do ifdef out the PCH.h and work on the non PCH version whenever I have some time to spare.
#ifdef USES_PCH
#include "PCH.h"
#elif
// include only whats needed
#endif
I would like to avoid defining USES_PCH at command line and manually keep it in
sync with /Y that, besides from not being very elegant, would be a pain. There is a lot of configurations
and modules to juggle with and a lot of files that don't follow project defaults.
If Visual C++ defined a constant to indicate whether precompiled headers were in use, it would probably be listed in Predefined Macros. And it's not documented there, so it probably doesn't exist. (If it does exist, it's probably undocumented and may change in a future version.)
This will not work, when using precompiled headers in Visual C++, you cannot even have any code before including a precompiled header. I was trying to do something similar, when I came across your question. After a little trial and error, I have found that there can be no code prior to the #include directive for the precompiled header when using the /Yu compiler option.
#ifdef USES_PCH
#include "stdafx.h"
#endif
result: fatal error C1020: unexpected #endif
As far as I know, it can't, but there are some heuristics: VC++ uses StdAfx.h, Borland uses #pragma hdrstop, etc.
I am working on a large C++ project in Visual Studio 2008, and there are a lot of files with unnecessary #include directives. Sometimes the #includes are just artifacts and everything will compile fine with them removed, and in other cases classes could be forward declared and the #include could be moved to the .cpp file. Are there any good tools for detecting both of these cases?
While it won't reveal unneeded include files, Visual studio has a setting /showIncludes (right click on a .cpp file, Properties->C/C++->Advanced) that will output a tree of all included files at compile time. This can help in identifying files that shouldn't need to be included.
You can also take a look at the pimpl idiom to let you get away with fewer header file dependencies to make it easier to see the cruft that you can remove.
PC Lint works quite well for this, and it finds all sorts of other goofy problems for you too. It has command line options that can be used to create External Tools in Visual Studio, but I've found that the Visual Lint addin is easier to work with. Even the free version of Visual Lint helps. But give PC-Lint a shot. Configuring it so it doesn't give you too many warnings takes a bit of time, but you'll be amazed at what it turns up.
There's a new Clang-based tool, include-what-you-use, that aims to do this.
!!DISCLAIMER!! I work on a commercial static analysis tool (not PC Lint). !!DISCLAIMER!!
There are several issues with a simple non parsing approach:
1) Overload Sets:
It's possible that an overloaded function has declarations that come from different files. It might be that removing one header file results in a different overload being chosen rather than a compile error! The result will be a silent change in semantics that may be very difficult to track down afterwards.
2) Template specializations:
Similar to the overload example, if you have partial or explicit specializations for a template you want them all to be visible when the template is used. It might be that specializations for the primary template are in different header files. Removing the header with the specialization will not cause a compile error, but may result in undefined behaviour if that specialization would have been selected. (See: Visibility of template specialization of C++ function)
As pointed out by 'msalters', performing a full analysis of the code also allows for analysis of class usage. By checking how a class is used though a specific path of files, it is possible that the definition of the class (and therefore all of its dependnecies) can be removed completely or at least moved to a level closer to the main source in the include tree.
I don't know of any such tools, and I have thought about writing one in the past, but it turns out that this is a difficult problem to solve.
Say your source file includes a.h and b.h; a.h contains #define USE_FEATURE_X and b.h uses #ifdef USE_FEATURE_X. If #include "a.h" is commented out, your file may still compile, but may not do what you expect. Detecting this programatically is non-trivial.
Whatever tool does this would need to know your build environment as well. If a.h looks like:
#if defined( WINNT )
#define USE_FEATURE_X
#endif
Then USE_FEATURE_X is only defined if WINNT is defined, so the tool would need to know what directives are generated by the compiler itself as well as which ones are specified in the compile command rather than in a header file.
Like Timmermans, I'm not familiar with any tools for this. But I have known programmers who wrote a Perl (or Python) script to try commenting out each include line one at a time and then compile each file.
It appears that now Eric Raymond has a tool for this.
Google's cpplint.py has an "include what you use" rule (among many others), but as far as I can tell, no "include only what you use." Even so, it can be useful.
If you're interested in this topic in general, you might want to check out Lakos' Large Scale C++ Software Design. It's a bit dated, but goes into lots of "physical design" issues like finding the absolute minimum of headers that need to be included. I haven't really seen this sort of thing discussed anywhere else.
Give Include Manager a try. It integrates easily in Visual Studio and visualizes your include paths which helps you to find unnecessary stuff.
Internally it uses Graphviz but there are many more cool features. And although it is a commercial product it has a very low price.
You can build an include graph using C/C++ Include File Dependencies Watcher, and find unneeded includes visually.
If your header files generally start with
#ifndef __SOMEHEADER_H__
#define __SOMEHEADER_H__
// header contents
#endif
(as opposed to using #pragma once) you could change that to:
#ifndef __SOMEHEADER_H__
#define __SOMEHEADER_H__
// header contents
#else
#pragma message("Someheader.h superfluously included")
#endif
And since the compiler outputs the name of the cpp file being compiled, that would let you know at least which cpp file is causing the header to be brought in multiple times.
PC-Lint can indeed do this. One easy way to do this is to configure it to detect just unused include files and ignore all other issues. This is pretty straightforward - to enable just message 766 ("Header file not used in module"), just include the options -w0 +e766 on the command line.
The same approach can also be used with related messages such as 964 ("Header file not directly used in module") and 966 ("Indirectly included header file not used in module").
FWIW I wrote about this in more detail in a blog post last week at http://www.riverblade.co.uk/blog.php?archive=2008_09_01_archive.xml#3575027665614976318.
Adding one or both of the following #defines
will exclude often unnecessary header files and
may substantially improve
compile times especially if the code that is not using Windows API functions.
#define WIN32_LEAN_AND_MEAN
#define VC_EXTRALEAN
See http://support.microsoft.com/kb/166474
If you are looking to remove unnecessary #include files in order to decrease build times, your time and money might be better spent parallelizing your build process using cl.exe /MP, make -j, Xoreax IncrediBuild, distcc/icecream, etc.
Of course, if you already have a parallel build process and you're still trying to speed it up, then by all means clean up your #include directives and remove those unnecessary dependencies.
Start with each include file, and ensure that each include file only includes what is necessary to compile itself. Any include files that are then missing for the C++ files, can be added to the C++ files themselves.
For each include and source file, comment out each include file one at a time and see if it compiles.
It is also a good idea to sort the include files alphabetically, and where this is not possible, add a comment.
If you aren't already, using a precompiled header to include everything that you're not going to change (platform headers, external SDK headers, or static already completed pieces of your project) will make a huge difference in build times.
http://msdn.microsoft.com/en-us/library/szfdksca(VS.71).aspx
Also, although it may be too late for your project, organizing your project into sections and not lumping all local headers to one big main header is a good practice, although it takes a little extra work.
If you would work with Eclipse CDT you could try out http://includator.com to optimize your include structure. However, Includator might not know enough about VC++'s predefined includes and setting up CDT to use VC++ with correct includes is not built into CDT yet.
The latest Jetbrains IDE, CLion, automatically shows (in gray) the includes that are not used in the current file.
It is also possible to have the list of all the unused includes (and also functions, methods, etc...) from the IDE.
Some of the existing answers state that it's hard. That's indeed true, because you need a full compiler to detect the cases in which a forward declaration would be appropriate. You cant parse C++ without knowing what the symbols mean; the grammar is simply too ambiguous for that. You must know whether a certain name names a class (could be forward-declared) or a variable (can't). Also, you need to be namespace-aware.
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)
If there's a particular header that you think isn't needed anymore (say
string.h), you can comment out that include then put this below all the
includes:
#ifdef _STRING_H_
# error string.h is included indirectly
#endif
Of course your interface headers might use a different #define convention
to record their inclusion in CPP memory. Or no convention, in which case
this approach won't work.
Then rebuild. There are three possibilities:
It builds ok. string.h wasn't compile-critical, and the include for it
can be removed.
The #error trips. string.g was included indirectly somehow
You still don't know if string.h is required. If it is required, you
should directly #include it (see below).
You get some other compilation error. string.h was needed and isn't being
included indirectly, so the include was correct to begin with.
Note that depending on indirect inclusion when your .h or .c directly uses
another .h is almost certainly a bug: you are in effect promising that your
code will only require that header as long as some other header you're using
requires it, which probably isn't what you meant.
The caveats mentioned in other answers about headers that modify behavior
rather that declaring things which cause build failures apply here as well.