предупреждение gcc "будет инициализировано после"


228

Я получаю много этих предупреждений из стороннего кода, который не могу изменить. Есть ли способ отключить это предупреждение или хотя бы отключить его для определенных областей (например, #pragma push / pop в VC ++)?

Пример:

list.h:1122: warning: `list<LogOutput*, allocator<LogOutput*> >::node_alloc_' will be initialized after 
list.h:1117: warning:   `allocator<LogOutput*> list<LogOutput*, allocator<LogOutput*> >::alloc_'

Можете ли вы опубликовать пару строк фактических предупреждений? А также скажите, если это C, C ++, и если у вас есть источник, если предупреждение приходит от компоновщика или процесса компиляции?
— csl

Ответы:


371

Убедитесь, что члены отображаются в списке инициализатора в том же порядке, что и в классе

Class C {
   int a;
   int b;
   C():b(1),a(2){} //warning, should be C():a(2),b(1)
}

или вы можете включить -Wno-reorder


91
Почему это важно, кстати? Почему существует это предупреждение?
— Eloff

40
@Eloff В некоторых случаях (не рекомендуется) bи aинициализация может зависеть друг от друга. Наивный пользователь может попытаться изменить порядок инициализации, чтобы получить какой-то эффект, и Предупреждение даст понять, что оно не работает.
— Горпик

24
Таким образом, порядок объявлений имеет семантическое значение, даже если между объявлениями нет никакой связи? Как бессмысленно!
— Cuadue

10
Это не объясняет, почему существует это предупреждение, и приводит ссылки -Wno-reorderбез упоминания, к каким проблемам это может привести. Я знаю, что ОП не спрашивал никаких других подробностей, но такой высоко оцененный ответ, я бы ожидал хотя бы упомянуть контекст и предостережения вокруг этого. Разве мы не должны отвечать на вопрос, который должен был написать ОП ?
— underscore_d

4
Члены @ cp.engr инициализируются в порядке их объявления, а не в порядке их инициализации в списке инициализации - поэтому, если инициализация члена зависит от другого, но объявления меняются местами, поэтому зависимый объект инициализируется после своего зависимого, кого-то очень скоро будет очень плохое время, так как это чистый UB.
— underscore_d


17

Для тех, кто использует QT с этой ошибкой, добавьте это в .pro файл

QMAKE_CXXFLAGS_WARN_ON += -Wno-reorder

7

использовать -Wno-reorder(man gcc твой друг :))


6
Ух ты, ты нашел новый способ сказать RT_M: MIYF (мужчина твой друг) Если ты не возражаешь, я собираюсь использовать его :)
— Oren S

4

Если вы видите ошибки из библиотечных заголовков и используете GCC, вы можете отключить предупреждения, включив -isystemвместо них заголовки -I.

Подобные функции существуют в Clang .

Если вы используете CMake, вы можете указать SYSTEMдля include_directories.


Можете ли вы объяснить, как "указать SYSTEM"?
— einpoklum

1
Просто поместите строку `SYSTEM` в конце include_directoriesстроки.
— Дрю Ноакс

1

Порядок инициализации не имеет значения. Все поля инициализируются в порядке их определения в своем классе / структуре. Но если порядок в списке инициализации другой, gcc / g ++ генерирует это предупреждение. Измените только порядок инициализации, чтобы избежать этого предупреждения. Но вы не можете определить поле с помощью инициализации до его создания. Это будет ошибка во время выполнения. Таким образом, вы меняете порядок определения. Будьте осторожны и сохраняйте внимание!


ОП хотела знать, как отключить предупреждение, а не то, что оно означает или как исправить код. Фактически, сообщение говорит, что код является сторонним и не может быть изменен. Они не могут изменить порядок определения и, возможно, не порядок инициализации.
— Тим Сегин

он очень делает дело , если второй объект в списке инициализации является initd с 1 - го объекта, но они объявили неправильный путь вокруг в заголовке. в этом случае все может стать очень странным.
— underscore_d

0
Class C {
   int a;
   int b;
   C():b(1),a(2){} //warning, should be C():a(2),b(1)
}

порядок важен, потому что если a инициализируется до b, а a зависит от b. Появится неопределенное поведение.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.