🔒 Locked

Annoying warning: 'x' intialized after 'y'

Started by Qoy Apr 16, 2005 at 11:40 PM 9 replies 4.7k views

Original Post

Apr 16, 2005 at 11:40 PM

I'm moving a project from VC7 to GCC under Mac OSX, and I'm getting a bunch of the warning that says some variable will be initialized after some other... caused when you have a constructor initializer list with variables in a different order from that in which they're declared in the class declaration, ie:


class A
{
public:
  A();

  int mX;
  int mY;
};

A::A() : mY(0), mX(0)
{
}

The above is the type of situation that causes the warning. Is there a flag to disable this warning? I couldn't see anything in the gcc man file or the Xcode build options. I could just switch around the initializations so they're in the right order, but that's a little annoying since there's kind of a lot of code, and I know the order in which the initializations will be run with or without the warning.

255

Apr 17, 2005 at 2:21 AM

According to the GCC man-page -Wreorder turns this warning on. What you want then is -Wno-reorder.

Skizz

Apr 17, 2005 at 4:16 AM

This is mentioned in Scott Myers excellent 'Effective C++'. There's a good reason for this to happen and I think the standard specifies the order of items in the initialiser list should match the order they are declared in the class. I don't have the book to hand so I can't tell you what that reason is.

Skizz

Qoy

Apr 17, 2005 at 3:57 PM

Thanks for the info, I'll use that option now.

Skizz,

I believe the standard says that the order of initialization will match the order of declaration in the class declaration, regardless of what order you type the members in the initializer list.

Anon Mike

Apr 18, 2005 at 2:17 PM

Turning off warnings is usually bad. Unless you have to ship tomorrow or something then IMHO you should just take the hit now and fix the code. The warning is there because it's fairly common for people to (wrongly) assume that members are initialized in the order given in the initializer list and then they end up with screwed dependencies and random heap corruption.

Turning off the warning will fix the immediate pain but the next guy that comes along is going to hate you after he spends a week debugging something that would have been found the first time the code was compiled if the warning wasn't turned off.

Fruny

Apr 18, 2005 at 2:18 PM

I'm with Anon Mike on that one.

SirLuthor

Apr 18, 2005 at 2:28 PM

Quote:
Original post by Anon Mike
Turning off warnings is usually bad. Unless you have to ship tomorrow or something then IMHO you should just take the hit now and fix the code. The warning is there because it's fairly common for people to (wrongly) assume that members are initialized in the order given in the initializer list and then they end up with screwed dependencies and random heap corruption.

Turning off the warning will fix the immediate pain but the next guy that comes along is going to hate you after he spends a week debugging something that would have been found the first time the code was compiled if the warning wasn't turned off.

You say that turning off warnings is bad. However, what about (in my eyes) useless warnings such as 4786 I think it was, that function names are too long, and are truncated to 255 characters in debug mode (happens a lot when passing stl containers around)? Surely it's not going to kill anyone to turn that sort of thing off?

Qoy: Is it that much trouble to initialize mX before mY? It will make things clearer for people looking through your code, as well as avoiding the aformentioned warning?

Fruny

Apr 18, 2005 at 2:33 PM

Quote:
Original post by SirLuthor
You say that turning off warnings is bad. However, what about (in my eyes) useless warnings such as 4786 I think it was, that function names are too long, and are truncated to 255 characters in debug mode

Warnings are good. VC6 was not. [smile]

(it's type names, not function names)

SirLuthor

Apr 18, 2005 at 5:03 PM

Quote:
Original post by Fruny
Warnings are good. VC6 was not. [smile]

(it's type names, not function names)

Hehehe, yea, I probably should upgrade [smile]

Anon Mike

Apr 18, 2005 at 5:04 PM

Quote:
Original post by SirLuthor
You say that turning off warnings is bad. However, what about (in my eyes) useless warnings such as 4786 I think it was, that function names are too long, and are truncated to 255 characters in debug mode (happens a lot when passing stl containers around)? Surely it's not going to kill anyone to turn that sort of thing off?

The big difference between a warning for initializers being in the wrong order and a warning for debug symbols being to long is that the former is fixable via trivial code change. The latter is not fixable at all because you're running up against an inherent limitation of the compiler, not the language.

You have to use your judgement for these kind of things. I turn off a very few selected warnings myself - "unreferenced inline function" being my favorite. If you use non-standard compiler-specific features then you might need to turn off portability warnings about those - I use zero-length arrays in structures all the time for example and have to turn off warnings about those.

Sharlin

Apr 27, 2005 at 4:56 AM

But as Qoy said, the members *will* be initialized in the right order, even when you write the list in a wrong order; g++ will automatically rearrange the list:

sharlin@pleco:~$ cat foo.cpp && g++ foo.cpp -o foo && ./foo#include <iostream>struct foo { foo(int i) { std::cout<<i<<'\n'; } };struct bar { bar() : f2(2), f1(1) { } foo f1, f2; };int main(){  bar b;}12

Of course, I'm not saying that ignoring warnings in general is a good thing, but in this case it shouldn't matter too much.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.