특정 포함 파일에 대한 경고를 비활성화하는 방법은 무엇입니까?


79

특정 포함 파일에 의해 직접 또는 간접적으로 포함 된 모든 파일에 대해 특정 경고를 비활성화하고 싶습니다. 예를 들어, a에 포함 된 파일에 포함 된 모든 파일 또는 파일에 대해 "문자열 리터럴을 char *에 할당하고 있습니다"라는 경고를 비활성화하고 싶습니다 #include <bar/*>(제 경우 별표는 "여기에 모든 것이있을 수 있음"을 의미 함).

그 이유는 내가 프로그래밍해야하는 일부 사람들은 "const"를 사용할 수 없기 때문에 결국 특정 문자열 리터럴 남용에 대해 많은 경고를받습니다. 나는 그들의 코드에서 나오는 수천 개의 경고를 무시하고 싶습니다. 그래서 내 코드의 실수에 집중하고 수정할 수 있습니다.

Intel C ++ 및 GCC를 사용합니다. 내 친구 중 일부는 clang을 사용하므로 이에 대한 해결책을 듣고 기뻐할 것입니다.



이 권한을 얻었 습니까? 문제의 파일이에 포함 된 <bar/the_file.h>경우 경고가 표시 <the_file.h>되지 않고 표시되지 않아야합니까?
Xeo 2011-06-12

@Neil 관련 링크에 감사드립니다. 원치 않는 연관성이있을 수있는 다른 사람들을 위해 분명히하기 위해 : 위의 두 링크는 ​​복제 링크가 아닙니다!
Johannes Schaub-litb 2011-06-12

@Xeo는 특히 그렇지 않습니다. 해당 파일에 대한 모든 경고가 비활성화 된 상태로 살 수 있습니다. 특정 포함 패턴을 가질 필요는 없습니다. 나는 내 질문을 공식화 한 방식이 약간 불행하다고 생각합니다.
Johannes Schaub-litb 2011-06-12

어떤 컴파일러를 사용하고 있습니까? (경고를 억제하는 방법은 종종 컴파일러에 따라 다릅니다.)
Ben Hocking 2011 년

답변:


71

GCC를 사용할 때 -isystem플래그 대신 -I플래그를 사용하여 해당 위치에서 경고를 비활성화 할 수 있습니다.

따라서 현재 사용중인 경우

gcc -Iparent/path/of/bar …

사용하다

gcc -isystem parent/path/of/bar …

대신. 불행히도 이것은 특별히 세분화 된 컨트롤이 아닙니다. 좀 더 표적화 된 메커니즘을 알지 못합니다.


4
clang에는 --system-header-prefix = 옵션이 있습니다. clang.llvm.org/docs/…
dev_null

50

더 나은 GCC 솔루션 : #pragma를 사용하십시오.

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

예를 들면 :

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

이것은 내가 원하는 것이 아닙니다. "Qt"로 시작하는 모든 파일에 대해 경고를 비활성화하는 방법을 찾고 있습니다 (예를 유지하기 위해. 단일 명명 된 파일뿐 아니라 이미 진단 푸시 / 팝을 사용하지만 불행히도 파일 이름에 와일드 카드 일치를 수행 할 수 없습니다. 지금까지 우리가 본 적이있다.
요하네스 SCHAUB - litb

죄송합니다. 오해했습니다. AFAIK에서는 두 가지 선택 사항 만 있습니다. 문제의 모든 헤더를 포함하고 #pragma diagnostic에 래핑 된 헤더 파일을 먼저 포함하고 파일을 한 번만 처리하려면 다중 포함 가드를 사용하는 것입니다. 또는 -isystem을 사용하여 헤더를 시스템 헤더로 취급합니다. 포함 경로 (isystem의 동작을 넘어서)를 기반으로 사용자 지정 진단 규칙을 정의하는 방법이 없다고 생각합니다. 저는 항상이 문제에 대해 ""include_all_bar.h "파일 만들기"접근 방식을 사용했습니다.
Brad

13
이 답변이 최고 투표는 아니지만 매우 유용하다고 생각합니다. 원래 질문 (경로 / 접두사의 모든 라이브러리)을 충족하지는 못하지만 주어진 헤더 집합에 대한 일부 경고를 선택적으로 제외하는 방법을 제공합니다. 👍
benschumacher

36

내가 사용할 때 & co의 g++일반적인 기본값으로 수많은 경고를 생성하는 타사 헤더가 -Wall -Wextra있습니다. 나는 그들을 별도의 포함으로 그룹화하는 경향이 있습니다 .system_header #pragma

[...] GCC는 시스템 헤더에서 발견 된 코드를 특별 처리합니다. #warningGCC가 시스템 헤더를 처리하는 동안에는 (진단 참조) 생성 된 경고를 제외한 모든 경고 가 표시되지 않습니다. 시스템 헤더에 정의 된 매크로는 확장 될 때마다 몇 가지 경고에 영향을받지 않습니다. 이 면제는 시스템 헤더에 정의 된 매크로의 코드로 인해 경고가 많은 오탐을 생성하는 경우 임시로 부여됩니다.

[...]

#pragma GCC system_headerGCC에게 현재 포함 파일의 위치에 관계없이 시스템 헤더로 간주하도록 지시 하는 지시문도 있습니다 . #pragma파일에서 앞에 오는 코드는 영향을받지 않습니다. #pragma GCC system_header기본 소스 파일에는 영향을주지 않습니다.

이 솔루션은 -isystem더 세밀하고 명령 줄 인수와 포함 디렉터리를 너무 많이 사용하지 않고 소스에 직접 넣을 수 있기 때문에이 솔루션을 선호합니다 .

끔찍한 루트 라이브러리의 예 :

#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

2
오, 아주 좋아요. +1… 안타깝게도 이러한 파일은 다른 포함 파일 보다 먼저 오는 경향이 있으며 pragma를 적용하면 파일의 나머지 부분, 즉 모든 포함 파일에 영향을 미치는 것 같습니다 .
Konrad Rudolph

@Konrad Rudolph : 확실합니까? 하나의 포함과 하위 포함에만 해당되지 않습니까?
Amir Zadeh 2011 년

1
@Green 예, 그게 제가 의미하는 바입니다. 그럼에도 불구하고,이 중 목록을 포함하는 말에 모든 의심이 포함 넣어달라고 요구한다 (그리고 나는 종종 바람직하지 또는 수의 것을 말했듯이) 또는 모든 의심 넣어 당신이 다음을 포함 별도의 헤더에 포함되어 있습니다. 이것은 또한 대규모 공동 프로젝트에서 완벽한 옵션이 아닙니다.
Konrad Rudolph

2
@Konrad : 두 번째 해결책은 제가 채택한 해결책입니다.
Matteo Italia

0

가장 간단한 해결책은 파일 이름과 경고 유형에 따라 컴파일러를 호출하고, 컴파일하고, 원하지 않는 출력을 제거하는 간단한 스크립트를 작성하는 것입니다. 컴파일러마다 다른 스크립트를 사용할 수 있습니다.

컴파일러를 직접 호출하는 대신이 스크립트를 사용하도록 makefile을 업데이트하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.