2016-04-30 1 views
3

Я использую флаговые компиляции -Wall -Wextra и -Werror. Я получаю поток «объявленный« статический », но никогда не определяемый [-Werror = unused-function]« Предупреждения (обрабатываемые как ошибки) при компиляции следующего файла. Нет таких предупреждений, когда я изменяю порядок директив #include. Пожалуйста, помогите мне понять, почему?Почему я получаю предупреждения компиляции C++ в зависимости от порядка заголовка

Я знаю, что могу удалить дополнительные предупреждения и ошибки и получить свою программу для компиляции, ясно, что это не мое намерение, или мой код будет более интересным. Я пытаюсь получить более глубокое знание C++ и улучшить свои привычки, очистив предупреждения в своем коде.

Я понимаю, что argp на самом деле является библиотекой C, а iostream - это библиотека C++, возможно, это часть проблемы. Я был бы рад использовать правильную C++-библиотеку для выполнения того, что делает argp, но я не могу ее найти. Если есть, я был бы рад услышать об этом.

#include <argp.h> 
#include <iostream> 

int main(int argc, char **argv) 
{ 
    return 0; 
} 

Чтобы было ясно, я работаю над нетривиальной программы, и есть конкретные причины для желающих использовать C++ вместо C. Я сводились код, показанный здесь, чтобы как можно меньше кода, чтобы произвести эффект, который я пытаюсь понять. Пожалуйста, не предполагайте, что мне не нужен тот или иной заголовок.

Компилятор: GCC

:~/scratch/argp_example$ gcc --version 
gcc (Ubuntu 5.2.1-23ubuntu1~12.04) 5.2.1 20151031 Copyright (C) 2015 Free Software Foundation, Inc. 
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 

компилятор invokation: g++ -o obj/main.o -c src/main.cpp -Wall -Wextra -Werror -pedantic -MMD --std=c++11 -Iinc

Конкретная обратной связи составитель:

In file included from /usr/include/x86_64-linux-gnu/c++/5/bits/gthr.h:148:0, 
       from /usr/include/c++/5/ext/atomicity.h:35, 
       from /usr/include/c++/5/bits/ios_base.h:39, 
       from /usr/include/c++/5/ios:42, 
       from /usr/include/c++/5/ostream:38, 
       from /usr/include/c++/5/iostream:39, 
       from src/main.cpp:2: 
/usr/include/x86_64-linux-gnu/c++/5/bits/gthr-default.h:101:1: warning: ‘int __gthrw_pthread_once(pthread_once_t*, void (*)())’ declared ‘static’ but never defined [-Wunused-function] __gthrw(pthread_once)^

Есть много еще многие подобные ошибки из gthr.h. Эта конкретная копия/вставка была выполнена без запуска -Werror, но это единственное отличие.

РЕШЕНИЕ: Это был мой выбор решения, но, конечно, вы могли бы просто изменить порядок включений. Это признанная ошибка, поэтому нет «правильного» ответа, все решения будут обходными способами. По-моему, это, по-моему, наименее вероятно даст мне или другим возможность позже.

#include <argp.h> 
#undef __attributes__ 
#include <iostream> 
... 
+0

Это странная проблема. Возможно, вы можете ограничить синтаксический анализ одним модулем и * not * включить iostream в этом? – wallyk

+0

Выглядит как ошибка GNU: http://stackoverflow.com/questions/7969419/nvcc-cuda-3-1-ghtr-default-h-flood-of-declared-static-but-not-defined- warnin –

+0

Что касается заменителей, вы проверили [Boost.Program_options] (http://www.boost.org/doc/libs/1_60_0/doc/html/program_options.html)? –

ответ

4

Это known bug. Виновником этот кусок кода в argp.h, который срабатывает при использовании -std=c++xx:

#ifndef __attribute__ 
/* This feature is available in gcc versions 2.5 and later. */ 
# if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) || __STRICT_ANSI__ 
# define __attribute__(Spec) /* empty */ 
# endif 

Заявления на вопрос, как правило, отмечены __attribute__ ((__weakref__("pthread_meow"))), но этот макрос вызывается этот атрибут испаряться.

Пока ошибка не исправлена, вы можете захотеть скомпилировать ее с помощью -std=gnu++xx или вручную #undef __attribute__ после включения argp.h.

+0

Не могли бы вы посоветовать, как лучше всего искать известные ошибки? Научите человека ловить рыбу ...? Мне не повезло в Google. – Jfevold

+0

@Jfevold Ну, я сначала понял, что вызывает его, а затем обыскал, является ли это известной проблемой. Используйте 'g ++ -E' для предварительной обработки обеих версий кода, проверьте, что другое (' __attribute__ ((__weakref __ ("..."))) 'ушел), затем проверьте, что вызывает его (argp.h, определяющий' __attribute__'), а затем google, чтобы узнать, является ли это известной проблемой (она входит в число лучших результатов для 'argp.h __attribute__'. –