DSP Module method name collision with global macro

dsp_module

#1

I am finally trying the dsp module for real but am running into a method naming collision with a globally defined macro called check().
In juce_FIRFilter and juice_IIRFilter there are methods called check() and due to including <Cocoa/Cocoa.h> in another spot, my project includes AssertMacros.h from the Mac OS X SDK 10.12 which contains

#ifndef check
#define check(assertion)  __Check(assertion)
#endif

This leads to build errors “Expected member name…” because the macro gets replaced.
Has anyone else seen this? Is there an easy fix? IMHO check() is a terrible method name and should be changed (maybe to checkCoefficients()?) and that would solve the issue.


#2

I agree, check() is a little ambiguous. Personally I think validate() or validateCoefficients() would be a better name for this method.


#3

As a solution, does it help to include the Cocoa.h after the Juce includes? If it still complains, you can add an #undef check between the juce headers and the cocoa includes maybe?

#defines in general are annoying for exactly that reasons, so I agree, to generic names should be avoided


#4

What is terrible is that some OS X headers define macros without caring about polluting everybody’s code. Fortunately there is a way to prevent that: add __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0 to the preprocessor defines (or add a #define __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES 0 before including the Cocoa header).

From the AssertMacros.h header:


#5

See:

Rail