Reputation: 6797
Pretty sure I know the answer to this one (thinking no), but could one safely accept/return std::function
by value in an API (across module boundaries)?
I'm thinking 'no' as I don't think there are any guarantees that one vendor's std::function
implementation is compatible with the other's. Is that the case?
If the answer is no as I suspect, how do you all deal with this kind of thing? I might have to resort to implementing my own or just avoid things like std::function
all together (ex: work with function pointers or functionoids). :-( I've found myself doing that in many cases before (reinventing a lot of the standard C++ library and certainly regrettably as even making our own STL-compliant vector type with support for both range ctor and fill ctor, custom allocators, etc. was certainly not fun and I doubt it was as good as standard implementations) simply because one might dynamically link to a library that has, say, MSVC 2010's implementation of std::function from a binary written in mingw, e.g.
The alternative, of course, is to not use these kinds of C++ features at all in our API and use, say, a C interface, but that would come at a rather heavy cost to us since we use our API as the central API for both internal and third party development.
Upvotes: 7
Views: 2177
Reputation: 473926
You can do it, so long as everyone's playing by the same rules, and your standard library is dynamically linked. If third-parties know that they must use a certain compiler, and a certain version of that compiler, with certain specific build flags, then there's no problem.
Even if you write your own wrapper, they have to use a specific version of that wrapper, though obviously that's a bit easier to enforce.
But really, that's the price you pay for trying to inter-operate via DLLs: everyone has to be on the same page, or else it won't work. Or you have to stick with basic types or home-grown, controlled interfaces.
Upvotes: 9