Fix some C++11 compilation error

[vincele]

Clang++-3.6 errors out with the following diagnostic message :

Code: Select all

In file included from FreeOrion-llvm/GG/src/GUI.cpp:44:
In file included from FreeOrion-llvm/GG/src/GIL/extension/io/png_io.hpp:41:
In file included from FreeOrion-llvm/GG/src/GIL/extension/io/png_io_private.hpp:26:
In file included from FreeOrion-llvm/GG/src/GIL/extension/io/../../gil_all.hpp:26:
FreeOrion-llvm/GG/src/GIL/extension/io/../../channel_algorithm.hpp:54:85: error: non-type template argument evaluates to -1, which cannot be narrowed to type 'unsigned long' [-Wc++11-narrowing]
struct unsigned_integral_max_value : public mpl::integral_c<UnsignedIntegralChannel,-1> {};
                                                                                    ^
FreeOrion-llvm/GG/src/GIL/extension/io/../../channel_algorithm.hpp:204:19: note: in instantiation of template class 'boost::gil::detail::unsigned_integral_max_value<unsigned long>' requested here
        if (src > unsigned_integral_max_value<uintmax_t>::value - div2)
                  ^
1 error generated.
GG/src/CMakeFiles/GiGi.dir/build.make:376: recipe for target 'GG/src/CMakeFiles/GiGi.dir/GUI.cpp.o' failed

The attached patch fixes it, hopefully in the right way...

[The extension diff has been deactivated and can no longer be displayed.]

[Mitten.O]

I tried on ubuntu clang 3.4 and did not see the error, but on the other hand the patch does not seem to break anything either.

[Geoff the Medio]

No apparent effects for me.

[vincele]

No apparent effects for me.

Not all compilers support C++11, and even fewer default to this mode... So we can keep this patch under the pillow until other compilers get to the same point. The g++-4.8 that I'm also using does not complain about that. I'm only using clang++-3.6 for testing its code sanitizers, and look at what falls out...

[Geoff the Medio]

So we can keep this patch under the pillow until other compilers get to the same point.

If it doesn't break any builds, but does fix some, then why not commit it?

[Vezzra]

If it doesn't break any builds, but does fix some, then why not commit it?

It might break compatibility with OSX 10.6. Which is bound to happen at some point anyway of course.

[Geoff the Medio]

Wrap it in an #ifdef then?

[vincele]

If it doesn't break any builds, but does fix some, then why not commit it?

It might break compatibility with OSX 10.6. Which is bound to happen at some point anyway of course.

I'm not sure it'll break there, llvm is being used by apple as its main compiler, so it'll probably just work, but until tested we cannot know. I don't like the idea of having an ifdef for that kind of things. Does someone build on osx 10.6 and can test the patch prior to commit ?

[Vezzra]

Does someone build on osx 10.6 and can test the patch prior to commit ?

Building on 10.6 doesn't work anymore with the current SDK, but the FO app should still run on it. I should be able to test if a build with your patch runs on 10.6 today evening.

[Vezzra]

I should be able to test if a build with your patch runs on 10.6 today evening.

Just did my test, no problems with the patch on OSX 10.6.

[vincele]

I should be able to test if a build with your patch runs on 10.6 today evening.

Just did my test, no problems with the patch on OSX 10.6.

Thanks a lot. I think this patch is now OK to be committed ?

[Geoff the Medio]

Committed.

[vincele]

Thanks