[MaNGOS-One][Patch] Fixed some GCC compiler warnings

[evilatwow]

Patch made against ManGOS One s1434.

I took the liberty to get rid of a few hundred GCC compiler warnings when building MaNGOS. I just changed a handful of initializer lists where members were not in the order mentioned in the class definition.

This fixes compiler warnings like this:

src/game/GridNotifiers.h: In constructor 'MaNGOS::NearestGameObjectEntryInPosRangeCheck::NearestGameObjectEntryInPosRangeCheck(const WorldObject&, uint32, float, float, float, float)':

src/game/GridNotifiers.h:642: warning: 'MaNGOS::NearestGameObjectEntryInPosRangeCheck::i_z' will be initialized after

src/game/GridNotifiers.h:641: warning: 'uint32 MaNGOS::NearestGameObjectEntryInPosRangeCheck::i_entry'

src/game/GridNotifiers.h:620: warning: when initialized here

src/game/GridNotifiers.h: In constructor 'MaNGOS::GameObjectEntryInPosRangeCheck::GameObjectEntryInPosRangeCheck(const WorldObject&, uint32, float, float, float, float)':

src/game/GridNotifiers.h:671: warning: 'MaNGOS::GameObjectEntryInPosRangeCheck::i_z' will be initialized after

src/game/GridNotifiers.h:670: warning: 'uint32 MaNGOS::GameObjectEntryInPosRangeCheck::i_entry'

src/game/GridNotifiers.h:653: warning: when initialized here

I also removed the <iostream> include in GridNotifiers.h, because I don't see why it is needed.

Patch: http://paste2.org/p/1799751

[sart13]

may be more simple update your GCC?

[evilatwow]

And it's even easier to pipe the build output to /dev/null, so I don't see any other warnings either!

But that's not the point. It's trivial to fix those warnings, so why wouldn't we just fix them?

[stfx]

Stuff like this should definately be patched against master because its in no way only One related as they have the same related code. And therefore should be reviewed by master devs

[Schmoozerd]

yes indeed.

But not time yet - but will adress this;

Actually I do think this is very valuable contribution

[zergtmn]

I don't see point in bothering about this type of warning ('a' will be initialized after 'b'). This one I'd always leave disabled.

[evilatwow]

There is not much point for well written code. The only point I can see for them is a 'stupidity check' for people that use their own members in initializer lists. Like this:

struct A
{
  A() : j(0), i (j) {}
  int i, j;
};

You'd be surprised how many bugs I've discovered in my professional life using that warning. But that aside... my point is this warning is apparently on by default for MaNGOS and a handful of headers are causing so many warnings - because they are included everywhere - that we don't see the real warnings any more. Since a fix for them is trivial, I didn't see why I wouldn't fix them.

In a perfect world, all code compiles warning free with -Wall

[faramir118]

Reordering the initialization list probably isn't the "proper" fix in all cases, since members are actually initialized in the order they are declared:

class c
{
 type a;
 type* b;

c(type* b_in) : b(b_in), a(b) { } // a(b) actually happens first, when b is uninitialized!
};

The above could cause crashes. If mangos has this problem, reordering the initialization list will hide the probelm.

Something to just be aware of...

edit: evilatwow kind of beat me to it

[FunkyBit]

I agree that is it worth to fix warnings.

If there is NO problem with the code that produces warnings... why are there warnings? So warnings exist for a reason. So the should be fixes if possible.

Easy conclusion.

So thanks for taking care about these warnings!

[VladimirMangos]

Independent how you write order of fields initialization C++ required call initialize code in order of declarations. If initialization order affect code work correctness then warning can show real bugs. So better fix code to expected order (with check that this will provide correct code work).

Disable warning will just hide _real_ problem possible.

P.S. Oh, faramir118 already clarify this)

P.S.2 And evilatwow ^^

[zergtmn]

You'd be surprised how many bugs I've discovered in my professional life using that warning.

I've never seen related bugs because I try to avoid dangerous code.

When I need to initialize one field with another I just write it in constructor body. In this case order of initialization cannot be altered by accidental field rearrangement (that happens sometimes).

Btw, VC++ doesn't have such warning at all.

In a perfect world, all code compiles warning free with -Wall

In reality even standard libraries cannot be compiled without warnings under /Wall.