a raw function pointer implicitly converts to a std::function, a lambda implicitly converts to a std::function, and a lambda without a capture implicitly converts to a raw function pointer. So I think it’s all fine. As long as the return type and argument types are equal you can use the same client code with both versions. Maybe I overlooked something?
I could be wrong here because I’ve not tried it but I don’t think it will break because a std::function can take a static function with the same signature as its argument. It will just wrap it up and forward the call to it.
It does however mean keeping two implementations as you’ll need both the pointer and std::function object in the class declaration/definition but I don’t think there’s that many places it’s used.
Yeah, meditating a bit more on this code, the C++11 standard says:
9.5 Unions [class.union]
2 […] If any non-static data member of a union has a non-trivial default constructor (12.1), copy constructor (12.8), move constructor (12.8), copy assignment operator (12.8), move assignment operator (12.8), or destructor (12.4), the corresponding member function of the union must be user-provided or it will be implicitly deleted (8.4.3) for the union.
I don’t see how this would work? Could you please explain a bit more what exactly you mean, that would be really helpful!
We already do some C++11 stuff that can be kept backward compatible (nullptr , override etc). But If we really want to leverage lambdas, variadic templates, move semantics etc. in common JUCE code, we need to either sprinkle the whole code with more #ifdef's and maintain double implementations everywhere (not really an option I think ) or we need to break compatibility with C++98 and pre-2013 Visual Studio at some point.
So the actual question is really: should we do it or not?
I’m all for breaking compatibility. I’d rather my code suddenly stop compiling than silently be behaving differently depending on the compiler.
We already use C++11 in Tracktion and as far as I can tell the only platform we can no longer target is < OS X 10.7. Not really a big deal. I’ve only had two customers ask for it in 2 years.
The real problem is that it’s going to be a big change if done fully i.e. replace all ScopedPointer’s with std::unique_ptr. So I’d rather see this done gradually so we can update our code in increments (even if all the JUCE commits come at once, it would be nice to have them split up so we can mirror the process).
Yeah I also know of companies that successfully build and ship AAX plug-ins using VS2013 on Windows, and -std=c++11 on Xcode/Mac. However I also heard some people claiming that it would not work. So I’m not sure now what the exact situation is.
If OS X 10.6 is really the only platform we would break by going C++11, that’d be totally OK imho. People will just have to update their compilers, which is a good idea anyway, and obviously we’d announce this well in advance