'check' identifier not found. Having an undesirable #undef


#1

After successfully feeding JUCE as a static library to Unreal Engine 4 I'm still having issues when including lib to UE4 project headers.

I'm having this error:  myue4project.generated.cpp(157) : error C3861: 'check': identifier not found

Here's this line.

        check(OuterClass->GetClass());

I've found this #undef at juce_win32_WASAPI.cpp https://goo.gl/msQ07D , but I'm not sure it's the only one.

How do I handle that issue? Can I remove undef and rename check to, say, check_juce? 

Would that effect crossplatform usability? AFAIK Mac can work different here. 


#2

The place in the juce codebase where that macro is used is deep inside the cpp files, not the headers, so this code should all live in its own compile-unit.. What on earth are you doing that would mean that your own code follows it in the same compile pass, and thus gets effected by the macros that it defined/undefined internally?


#3

Epic Games has it's own complicated module targeting system, so I can't exactly  tell how is it getting effected. 'generated' files are generated automatically by an ue4 toolset so fighting it's consequences is what's left to me. 

I could use juce inclusion at cpps only which gives no errors, but that's not really comfortable. 


#4

Well, I could (and probably should) change that macro name to something less likely to cause a collision. But the reason I didn't bother was because I couldn't imagine what kind of weird, off-piste build people could have that'd actually include all the juce .cpp files (a vast amount of code!) rather than just building them as compile units.


#5

I own a license for a 4-ish days so I haven't yet figured out which parts of juce_core are unnecessary for me and just made a static lib with core.

Still if it looks like necessary parts (like sound output) are defining/undefining check macro and adding separate compile units won't help as ue4 would still make a 'generate.cpp' which would cause trouble. 


#6

Ah, I had a quick search of the codebase, and you're obviously talking about the "#undef check" that happens in juce_StandardHeaders.h, not the one in the cpps. That makes more sense!

Looking a bit further, it does seem that I can safely remove that undef if I rewrite some bits of public header code to work around this name-pollution. There are some uses of the symbol "check" inside the juce implementation too, but in there I can undef it privately without affecting anything else.

I've pushed this to github now if you want to give it a try..


#7

Thanks, Jules, anything works outstanding now.