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.
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.