Should we post compiler warnings from SFML?

[Kian]

I was wondering, should we bring up any warnings that the compiler throws at us here?

I've recently been working on tightening up my own code (proper documentation, turning up all warnings on the compiler, etc), and looking through the options in GCC I found a bunch of warnings not covered by -Wall (which is really counter-intuitive). Turning those on gave me a bit of work, and also pointed out some warnings from SFML itself.

I was just curious if we should bring these up at all. They're things like:

"..\..\libs\SFML-2.0-rc\include\SFML\System\Mutex.hpp | 48 |
warning: base class 'class sf::NonCopyable' has a non-virtual destructor."

and

"..\..\libs\SFML-2.0-rc\include\SFML\System\Mutex.hpp | 48 |
warning: 'class sf::Mutex' has pointer data members but does not override 'sf::Mutex(const sf::Mutex&)' or 'operator=(const sf::Mutex&)' "

It's actually just those two for a bunch of classes.

And I suppose I already brought it up, so not really much point asking if I should. Hmm. Sorry?

[Laurent]

Yes, warnings should always be reported. They can warn about potential future problems, and if not, they are at least annoying for people like you who use the maximum level warning.

However, these two warnings shouldn't be triggered, it seems like the compiler doesn't understand what I'm doing. sf::NonCopyable is not used polymorphically, it defines a private copy constructor and assignment operator. Which explains why the second warning shouldn' be triggered: classes that inherit from sf::NonCopyable have no copy constructor and assignment operator, because the base class' ones are not accessible.

For SFML, I enable the following warnings:

Code: [Select]

-Wall -Wextra -Wshadow -pedantic -Wno-longlong

[Nexus]

In fact, both warnings seem to be quite inappropriate in general (but ok, you requested explicitly the maximum amount of warnings):

1. Base class doesn't imply polymorphism, not every base class requires a virtual destructor.
2. There are many cases where pointers don't own their pointees, in which the compiler-generated copy constructor and assignment operator do the right thing.

[Laurent]

So maybe warnings that are neither in -Wall nor in -Wextra are only supposed to be activated in specific situations, and are not suited for the general case.

[eXpl0it3r]

I too can provide some compiler/linker warnings when compiling SFML 2rc (8327870c9f) (Debug & Release) for Windows 7 x64 static with static standard library:

• SFML\src\SFML\Audio\SoundBuffer.cpp(256): warning C4267: 'argument': Converting from 'size_t' to 'sf::Int32', possible loss of data
• SFML/src\SFML/Graphics/stb_image/stb_image.h(760): warning C4244: 'initialisation': Converting from '__int64' to 'int', possible loss of data
• SFML/src\SFML/Graphics/stb_image/stb_image.h(773): warning C4244: 'initialisation': Converting from '__int64' to 'int', possible loss of data
• SFML/Graphics/stb_image/stb_image_write.h(321): warning C4244: 'initialisation': Converting from '__int64' to 'int', possible loss of data
• sndfile.lib(libsndfile-1.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR is already defined in "openal32.lib(OpenAL32.dll)"; second definition ignored.
• sndfile.lib(libsndfile-1.dll) : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library.
• winmm.lib(WINMM.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR is already defined in "opengl32.lib(OPENGL32.dll)"; second definition ignored.
• winmm.lib(WINMM.dll) : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library.
• gdi32.lib(GDI32.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR is already defined in "opengl32.lib(OPENGL32.dll)"; second definition ignored.
• gdi32.lib(GDI32.dll) : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library.

[Laurent]

The first one can be fixed easily.

I don't want to touch stb_image myself, so I should contact the author instead.

I don't know if the linker errors can be avoided.

[Dalini]

Also you'll probably have a lot more warnings to correct if you plan to update SFML for C++11 one day.

As far as I can remember, I only got a couple of warnings about methods arguments that were not used (I was compiling with clang++).
I can't remember the source file, but if you're interested let me know and I'll find out.

[Laurent]

Also you'll probably have a lot more warnings to correct if you plan to update SFML for C++11 one day

Why?

As far as I can remember, I only got a couple of warnings about methods arguments that were not used (I was compiling with clang++).
I can't remember the source file, but if you're interested let me know and I'll find out.

Yes, I'm interested. I compile with CLang and the above flags, and get no warning (except in stb_image, and one caused by a bug in CLang).

[Dalini]

Also you'll probably have a lot more warnings to correct if you plan to update SFML for C++11 one day

Why?

I just meant that some C++11 warnings options such as -Wzero-as-null-pointer-constant will generate a lot of warnings until you correct them all.

As far as I can remember, I only got a couple of warnings about methods arguments that were not used (I was compiling with clang++).
I can't remember the source file, but if you're interested let me know and I'll find out.

Yes, I'm interested. I compile with CLang and the above flags, and get no warning (except in stb_image, and one caused by a bug in CLang).

I remember for instance the file SFML/System/Utf.inl. Some methods arguments were not used (as in In Utf<32>::next(In begin, In end)), but I can see that it has been fixed now, so nevermind that, sorry

[Laurent]

I just meant that some C++11 warnings options such as -Wzero-as-null-pointer-constant will generate a lot of warnings until you correct them all.

Obviously, these C++11 specific warnings won't be fixed since I will keep a C++03 compatible code (and thus not replace NULL with nullptr).