Skip to content
New issue

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

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

Already on GitHub? # to your account

Defining expect(...) macro as shorthand by default conflicts with C++ #143

Open
itsthejb opened this issue Apr 17, 2015 · 8 comments
Open

Comments

@itsthejb
Copy link

Hi all,

We have started mixing C++ into our projects now that we're using ComponentKit. Needless to say this brings up a few interoperability issues. In the case of Expecta, I noticed that defining the expect(...) macro as shorthand by default provides no way to avoid name conflicts with libstdc++ (in this case <iterator>). Whilst it's possible to just not import Expecta for these specs, this might be a nice-to-have worth addressing in a future release.

Thanks!

@orta
Copy link
Member

orta commented Apr 17, 2015

We switched it round because when Expecta becomes a framework, the #define EXPECTA_SHORTHAND isn't able to influence the defines inside the framework. Which meant that you always used the EXP_expect.

I'm open to ideas around how this could work though.

@robb
Copy link
Member

robb commented Apr 17, 2015

IIRC, the reason expect is a macro is to overload it for primitives and objects, right? If so, we could replace it with an overloaded static inline C-function (example from Asterism) which hopefully plays nicer with C++?

@robb
Copy link
Member

robb commented Apr 17, 2015

e.g.:

/// Someheader.h
static inline __attribute__((overloadable)) expect(NSInteger i) {
    EXP_expect(@(i)); // or whatever
}

@modocache
Copy link
Member

IIRC, the reason expect is a macro is to overload it for primitives and objects, right?

There's also the matter of populating the __FILE__ and __LINE__ parameters. Swift allows us to provide default parameters for these values, but in Objective-C we're forced to use a macro.

@robb
Copy link
Member

robb commented Apr 17, 2015

Ah, dang.

@modocache
Copy link
Member

@itsthejb Could you post the exact compilation error you're seeing? To reproduce, is it enough to simply import <Expecta/Expecta.h> and <ComponentKit/ComponentKit.h> in the same file?

@itsthejb
Copy link
Author

#import <Expecta/Expecta.h>
#import <ComponentKit/ComponentKit.h>
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/map:1468:47: error: no member named '_equal' in namespace 'std::__1'; did you mean 'equal'?
    return __x.size() == __y.size() && _VSTD::equal(__x.begin(), __x.end(), __y.begin());
                                       ~~~~~~~^
/Users/jc/dev/EyeEm/EyeEm/Pods/Headers/Public/Expecta/EXPMatchers+equal.h:5:20: note: expanded from macro 'equal'
#define equal(...) _equal(EXPObjectify((__VA_ARGS__)))
                   ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:1190:1: note: 'equal' declared here
equal(_InputIterator1 __first1, _InputIterator1 __last1, _InputIterator2 __first2, _BinaryPredicate __pred)
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/map:2015:47: error: no member named '_equal' in namespace 'std::__1'; did you mean 'equal'?
    return __x.size() == __y.size() && _VSTD::equal(__x.begin(), __x.end(), __y.begin());
                                       ~~~~~~~^
/Users/jc/dev/EyeEm/EyeEm/Pods/Headers/Public/Expecta/EXPMatchers+equal.h:5:20: note: expanded from macro 'equal'
#define equal(...) _equal(EXPObjectify((__VA_ARGS__)))
                   ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:1190:1: note: 'equal' declared here
equal(_InputIterator1 __first1, _InputIterator1 __last1, _InputIterator2 __first2, _BinaryPredicate __pred)
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/set:747:47: error: no member named '_equal' in namespace 'std::__1'; did you mean 'equal'?
    return __x.size() == __y.size() && _VSTD::equal(__x.begin(), __x.end(), __y.begin());
                                       ~~~~~~~^
/Users/jc/dev/EyeEm/EyeEm/Pods/Headers/Public/Expecta/EXPMatchers+equal.h:5:20: note: expanded from macro 'equal'
#define equal(...) _equal(EXPObjectify((__VA_ARGS__)))
                   ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:1190:1: note: 'equal' declared here
equal(_InputIterator1 __first1, _InputIterator1 __last1, _InputIterator2 __first2, _BinaryPredicate __pred)
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/set:1157:47: error: no member named '_equal' in namespace 'std::__1'; did you mean 'equal'?
    return __x.size() == __y.size() && _VSTD::equal(__x.begin(), __x.end(), __y.begin());
                                       ~~~~~~~^
/Users/jc/dev/EyeEm/EyeEm/Pods/Headers/Public/Expecta/EXPMatchers+equal.h:5:20: note: expanded from macro 'equal'
#define equal(...) _equal(EXPObjectify((__VA_ARGS__)))
                   ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:1190:1: note: 'equal' declared here
equal(_InputIterator1 __first1, _InputIterator1 __last1, _InputIterator2 __first2, _BinaryPredicate __pred)
^
4 errors generated.

Of course, if ComponentKit is imported first you can dodge this problem, but the doesn't really solve the problem that as a macro it has a lot of scope to stomp on things...

@programmerdave
Copy link

Any updates on this?

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

No branches or pull requests

5 participants