Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile errors when using fmtlib from Objective-C++. #380

Closed
jpetrie opened this issue Sep 9, 2016 · 3 comments
Closed

Compile errors when using fmtlib from Objective-C++. #380

jpetrie opened this issue Sep 9, 2016 · 3 comments

Comments

@jpetrie
Copy link

jpetrie commented Sep 9, 2016

Including fmtlib's format.h header from an Objective-C++ source file that has itself previously included any Objective-C foundation header (such as Foundation.h) will generate a compilation error (error: expected unqualified-id) in format.h due a conflict between fmtlib's check function and a check macro defined in Apple's AssertMacros.h file.

This was observed in Xcode 7.3.1 (7D1014).

One solution might be to rename the check function so that it doesn't conflict (for example, check_that); this is straightforward, but works (in theory) everywhere... provided the alternative name doesn't conflict with some other obscure macro.

Another option is to use #pragma push_macro to undefine the macro at the start of format.h and pop it back into existence at the end of the file. This approach relies on compiler-specific pragmas which work in GCC, LLVM and Visual Studio but may not be available on other compilers that fmtlib desires to support.

There is also the option, of course, to do nothing; the #pragma workaround can always be implemented by users if they really need it. However it might be useful to at least modify the documentation to note that this is an issue with Objective-C++ code.

I'd be happy to provide a PR for either approach, I'd just like some guidance on whether or not this is an issue considered worth fixing and what direction would be preferable.

@vitaut
Copy link
Contributor

vitaut commented Sep 9, 2016

Thanks for the bug report, but this has been fixed already (#350).

@vitaut vitaut closed this as completed Sep 9, 2016
@jpetrie
Copy link
Author

jpetrie commented Sep 9, 2016

Thanks, sorry about the duplicate.

@vitaut
Copy link
Contributor

vitaut commented Sep 9, 2016

No problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants