[Bug]: JUCE headers can fail guarding themselves against macros defined by windows.h
danra opened this issue · comments
Detailed steps on how to reproduce the bug
- Start an example GUI application on Windows
- Add the following to MainComponent.h:
#include <juce_core/juce_core.h>
#include <windows.h>
#include <juce_gui_basics/juce_gui_basics.h>
Get 20 errors (tested in VS2022) due to the min
and max
macros not being undefined properly (which JUCE does try to do, both by using NOMINMAX
and by #undef
ing them in a few places).
Replacing juce_gui_basics
with juce_gui_extra
gives even more errors due to the standard small
macro being used as an enum value in juce_PushNotifications.h
.
My attempted analysis at why JUCE's defenses aren't working properly:
juce_core.h
is first included.JUCE_CORE_INCLUDE_NATIVE_HEADERS
is not defined, sonative/juce_BasicNativeHeaders.h
isn't included and so neither iswindows.h
.juce_core.h
then undefines the standardsmall
macro on its own and some more macros injuce_StandardHeader.h
, but sincewindows.h
wasn't included these aren't defined anyway.windows.h
is then included without the usefulWIN32_LEAN_AND_MEAN
,NOMINMAX
etc.juce_gui_basics.h
is then included, butjuce_core.h
of course isn't included again because of the#pragma once
. So none of the#undef
s happen, and the standard Windows macros interfere with the JUCE definitions.
The above example is of course artificial, but we did actually get this in a more realistic scenario (also simplified here):
foo.cpp
:
#include "foo.h"
#include "bar.h"
#include <juce_gui_extra/juce_gui_extra.h>
...
Header bar.h
:
#pragma once
#include <juce_audio_processors/juce_audio_processors.h>
#include <third_party.h>
...
Header third_party.h
:
...
#include <windows.h>
...
What is the expected behaviour?
Including a juce module, followed by including windows.h
, followed by including another juce module should always work.
Operating systems
Windows
What versions of the operating systems?
all
Architectures
x86_64
Stacktrace
No response
Plug-in formats (if applicable)
No response
Plug-in host applications (DAWs) (if applicable)
No response
Testing on the develop
branch
The bug is present on the develop
branch
Code of Conduct
- I agree to follow the Code of Conduct
We also have this happening in Shortcircuit XT, constant warnings about NOMINMAX macro redefinition. We traced it to juce_BasicNativeHeaders.h not having a guard around that #define NOMINMAX
at around line 80-something.
Would be nice if this were guarded 🙂