Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Should we post compiler warnings from SFML?  (Read 3874 times)

0 Members and 1 Guest are viewing this topic.

Kian

  • Newbie
  • *
  • Posts: 44
    • View Profile
Should we post compiler warnings from SFML?
« on: May 08, 2012, 05:59:00 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Should we post compiler warnings from SFML?
« Reply #1 on: May 08, 2012, 06:36:36 pm »
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
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Should we post compiler warnings from SFML?
« Reply #2 on: May 08, 2012, 07:49:13 pm »
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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Should we post compiler warnings from SFML?
« Reply #3 on: May 08, 2012, 08:07:39 pm »
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.
Laurent Gomila - SFML developer

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10846
    • View Profile
    • development blog
    • Email
Re: Should we post compiler warnings from SFML?
« Reply #4 on: May 08, 2012, 08:56:45 pm »
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.
« Last Edit: May 08, 2012, 08:58:59 pm by eXpl0it3r »
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Should we post compiler warnings from SFML?
« Reply #5 on: May 09, 2012, 08:10:17 am »
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.
Laurent Gomila - SFML developer

Dalini

  • Newbie
  • *
  • Posts: 43
    • View Profile
Re: Should we post compiler warnings from SFML?
« Reply #6 on: May 09, 2012, 11:08:13 pm »
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.
"Inconsistency imposes mental friction into a developer's work that no IDE can fully remove."

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Should we post compiler warnings from SFML?
« Reply #7 on: May 10, 2012, 08:00:15 am »
Quote
Also you'll probably have a lot more warnings to correct if you plan to update SFML for C++11 one day
Why?

Quote
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).
Laurent Gomila - SFML developer

Dalini

  • Newbie
  • *
  • Posts: 43
    • View Profile
Re: Should we post compiler warnings from SFML?
« Reply #8 on: May 10, 2012, 11:07:49 pm »
Quote
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.

Quote
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 :P
"Inconsistency imposes mental friction into a developer's work that no IDE can fully remove."

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Should we post compiler warnings from SFML?
« Reply #9 on: May 11, 2012, 07:58:46 am »
Quote
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).
Laurent Gomila - SFML developer

 

anything