This warning isn't enabled by default by either -Wall or -Wextra, and
for a good reason. When I do that, it fires also for all uses of
Platform::Application, basically any subclass causes that warning to be
printed as well, even if given subclass is used just once, in an
anonymous namespace, and only through the MAGNUM_APPLICATION_MAIN()
macro. The only solution on Clang is to make such subclasses `final`,
but on GCC not even that helps and one is forced to really make the base
destructor virtual. Which doesn't achieve anything, only adds yet
another entry to the vtable.
So, in the SceneGraph it fixes one particular use case where the warning
was triggered, and since the fix isn't so invasive I'm fine with that.
For Platform I have no idea how an acceptable fix would look like, so I
hope nobody needs any of that anytime soon.
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102168, especially
the part saying "This warning should not be used.".
Used `#pragma warning(suppress: 4996)` before which was apparently doing
completely nothing. Switched to `#pragma warning(disable: 4996)` now.
Started to become problematic on latest MSVC 2017 update (19.11) -- the
UWP builds are failing because of implicit warning-as-error.
The enum was only two-state, in almost all cases it included unnecessary
branching and the non-default usage was too verbose, thus all
transformation functions were split into two variants, <transform>() and
<transform>Local(). The <transform>() behaves exactly like the previous
implementation with TransformationType::Global, the <transform>Local()
behaves like the previous implementation with TransformationType::Local.
The enum and original functions were kept, they are marked as deprecated
and will be removed in future release.
This is rather large changeset, I triple checked that the new (both
deprecated and non-deprecated) implementations work as intended, but
can't possibly test every possible use case, so I'm sorry if I messed
something up :-) Also there was probably some bug in internal virtual
function implementations before, it should be now fixed.
Previously (<= 4.9.0) it behaved similarly to MSVC 2013, but the issues
with missing inline functions of classes declared as extern template
appeared again. This way doesn't work with MSVC, so I need to maintain
two separate symbol exporting scenarios. Damn you, DLL hell.
The only places where they aren't absolute are:
- when header is included from corresponding source file
- when including headers which are not part of final installation (e.g.
test-specific configuration, headers from Implementation/)
Everything what was in src/ is now in src/Corrade, everything from
src/Plugins is now in src/MagnumPlugins, everything from external/ is in
src/MagnumExternal. Added new CMakeLists.txt file and updated the other
ones for the moves, no other change was made. If MAGNUM_BUILD_DEPRECATED
is set, everything compiles and installs like previously except for the
plugins, which are now in MagnumPlugins and not in Magnum/Plugins.