How to disable warnings for particular include files?

C++Suppress Warnings

C++ Problem Overview


I wold like to disable particular warnings for all files that are included, directly or indirectly, by particular include files. For example, I want to disable the warning "you are assigning a string literal to a char*", for all files or files included by files included by a #include <bar/*> (the star in my case means "anything may be here").

The reason is, some of the people I have to program with just can't use "const", so in the end I get lots of warnings about that particular string literal abuse. I would like to ignore those thousands of warnings coming from their code, so I can concentrate on the mistakes in my own code and fix them.

I use Intel C++ and GCC. Some of my buddies use clang, so I would be glad to hear solutions for that too.

C++ Solutions


Solution 1 - C++

When using GCC you can use the -isystem flag instead of the -I flag to disable warnings from that location.

So if you’re currently using

gcc -Iparent/path/of/bar …

use

gcc -isystem parent/path/of/bar …

instead. Unfortunately, this isn’t a particularly fine-grained control. I’m not aware of a more targeted mechanism.

Solution 2 - C++

A better GCC solution: use #pragma.

#pragma GCC diagnostic push 
#pragma GCC diagnostic ignored "-W<evil-option>"
#include <evil_file>
#pragma GCC diagnostic pop

for example:

#pragma GCC diagnostic push 
#pragma GCC diagnostic ignored "-Wunused-local-typedefs"
#include <QtXmlPatterns>
#pragma GCC diagnostic pop

Solution 3 - C++

When I use g++ and I have third party headers that generate tons of warnings with my usual defaults of -Wall -Wextra & co. I tend to group them in separate includes, specifying the system_header #pragma.

> [...] GCC gives code found in system headers special treatment. All warnings, other than those generated by #warning (see Diagnostics), are suppressed while GCC is processing a system header. Macros defined in a system header are immune to a few warnings wherever they are expanded. This immunity is granted on an ad-hoc basis, when we find that a warning generates lots of false positives because of code in macros defined in system headers. > >[...] > > There is also a directive, #pragma GCC system_header, which tells GCC to consider the rest of the current include file a system header, no matter where it was found. Code that comes before the #pragma in the file will not be affected. #pragma GCC system_header has no effect in the primary source file.

I prefer this solution to the -isystem one because it's more fine-grained and I can put it directly in the sources, without messing too much with command line arguments and include directories.

Example with the hideous root library:

#ifndef ROOTHEADERS_HPP_INCLUDED
#define ROOTHEADERS_HPP_INCLUDED
#ifdef __GNUC__
// Avoid tons of warnings with root code
#pragma GCC system_header
#endif
#include "TH1F.h"
#include "TApplication.h"
#include "TGraph.h"
#include "TGraph2D.h"
#include "TCanvas.h"
#endif

Solution 4 - C++

Copying my answer from a duplicate thread.

You could use suppression pragmas.

This is supported for GCC and VC++ compilers, and it looks like this:

#pragma warning(push)
#pragma warning(disable : 4244)
#pragma warning(disable : 4127)
#pragma warning(disable : 4512)
#include <boost/python.hpp>
#pragma warning(pop)

Here are the detailed specs:

Solution 5 - C++

I guess the simplest solution would be write a simple script that will call the compiler, compile, and strip the undesired output, based on the filename and warning type. You can use different scripts for each compiler.

Just update your makefile to use this script instead of calling the compiler directly.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionJohannes Schaub - litbView Question on Stackoverflow
Solution 1 - C++Konrad RudolphView Answer on Stackoverflow
Solution 2 - C++BradView Answer on Stackoverflow
Solution 3 - C++Matteo ItaliaView Answer on Stackoverflow
Solution 4 - C++Daniel TrugmanView Answer on Stackoverflow
Solution 5 - C++Gilad NaorView Answer on Stackoverflow