Jump to content

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


evilatwow

Recommended Posts

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

Link to comment
Share on other sites

  • 2 weeks later...

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 ;)

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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 ^^

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use