276

I am getting a lot of these warnings from 3rd party code that I cannot modify. Is there a way to disable this warning or at least disable it for certain areas (like #pragma push/pop in VC++)?

Example:

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_'
usr1234567
  • 21,601
  • 16
  • 108
  • 128
LK__
  • 6,515
  • 5
  • 34
  • 53
  • Can you please post a couple of lines of the actual warnings? And also tell if this is C, C++, and if you have the source, if the warning comes from the linker or compilation process? – csl Oct 14 '09 at 08:15

7 Answers7

480

Make sure the members appear in the initializer list in the same order as they appear in the class

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

or you can turn -Wno-reorder

uray
  • 11,254
  • 13
  • 54
  • 74
  • 120
    Why is this important btw? Why does this warning exist? – Eloff Sep 07 '12 at 13:52
  • 51
    @Eloff In some cases (not recommendable), `b` and `a` initialisation might depend on each other. A naive user might try to alter the initialisation order to get some effect and the Warning would make it clear that it doesn't work. – Gorpik Jan 28 '13 at 16:17
  • 1
    See also: http://stackoverflow.com/questions/1828037/whats-the-point-of-g-wreorder – Ber Jun 11 '13 at 10:14
  • 28
    So the order of declarations has semantic meaning, even if there's no relationship between the declarations? How pointless! – Cuadue Aug 26 '14 at 15:46
  • 15
    This does not explain _why_ this warning exists and cites `-Wno-reorder` without mentioning what problems that could lead to. I'm aware the OP didn't ask for any other details, but such a highly voted answer I'd expect to at least mention the context and caveats around this. Aren't we supposed to answer the question the OP _should_ have written? – underscore_d Sep 20 '15 at 20:38
  • @underscore_d, please tell us the problems you say `-Wno-reorder` could lead to. – cp.engr Apr 09 '18 at 17:58
  • 6
    @cp.engr members are initialised in the order of their declaration, not their order in the init-list - so, if a member's initialisation depends upon another, but the declarations get swapped so the depended-upon gets initialised after its dependent, someone will be having a very bad time very soon, as that's pure UB. – underscore_d Apr 09 '18 at 21:46
  • Because the compiler cannot reorder your statements. And It also cannot initialize the block the way it should giving the performance advantage that you gain by not using assignments. It slows down the initialization when they are out of order. – Dan Feb 04 '19 at 17:52
31

You can disable it with -Wno-reorder.

Lukáš Lalinský
  • 40,587
  • 6
  • 104
  • 126
18

For those using QT having this error, add this to .pro file

QMAKE_CXXFLAGS_WARN_ON += -Wno-reorder
phuclv
  • 37,963
  • 15
  • 156
  • 475
user1175197
  • 379
  • 4
  • 7
7

use -Wno-reorder (man gcc is your friend :) )

dtech
  • 47,916
  • 17
  • 112
  • 190
LaszloG
  • 719
  • 3
  • 5
  • 7
    Wow, you found a new way to say RT_M: MIYF (man is your friend) If you don't mind, I am going to use it :) – Oren S Oct 14 '09 at 09:45
7
Class C {
   int a;
   int b;
   C():b(1),a(2){} //warning, should be C():a(2),b(1)
}

the order is important because if a is initialized before b , and a is depend on b. undefined behavior will appear.

Samuel
  • 803
  • 8
  • 17
5

If you're seeing errors from library headers and you're using GCC, then you can disable warnings by including the headers using -isystem instead of -I.

Similar features exist in clang.

If you're using CMake, you can specify SYSTEM for include_directories.

Drew Noakes
  • 300,895
  • 165
  • 679
  • 742
1

The order of initialization doesn’t matter. All fields are initialized in the order of their definition in their class/struct. But if the order in initialization list is different gcc/g++ generate this warning. Only change the initialization order to avoid this warning. But you can't define field using in initialization before its construct. It will be a runtime error. So you change the order of definition. Be careful and keep attention!

user1741137
  • 4,949
  • 2
  • 19
  • 28
Anatoly
  • 23
  • 1
  • The OP wanted to know how to disable the warning, not what it means or how to fix the code. In fact, the post says the code is third party and cannot be modified. They cannot change the order of definition and probably not the order of initialization either. – Tim Seguine Sep 03 '13 at 17:03
  • 3
    it very much **does** matter if the 2nd object in the init list is initd from the 1st object, but they're declared the wrong way around in the header. in that case, things could get very weird. – underscore_d Dec 06 '15 at 18:01