On 20/08/2018 16:46, Edward Diener wrote:
On 8/19/2018 4:37 PM, Peter Dimov wrote:
But if you compile the library with C++03, and the user code with C++11, it doesn't. The user code tries to call Y::f(X&&), and it's not there.
I do not think this will occur. If the shared library is statically loaded the linker will resolve the issue and tell you that Y::f(X&&) is not there at link time, and if the shared library is dynamically loaded whatever functionality which you call at run-time to get the address of Y::f(X&&) will fail.
I can see the case where you expect a call to resolve to Y::f(X&&) but because the library is built as c++03 it resolves to Y::f(X const &) instead, but that is to be expected unless the end-user does not know that he is using a c++03 shared library.
The problem is that the headers are compiled as C++11 (because they're included by that translation unit) while the source was compiled as C++03. Thus this is a link error -- the header specified that the move constructor should be present, but the compiled library does not contain it.
I am not saying that it is not a problem when a library with the same name is rebuilt with different public functionality for an end-user of that library. This can theoretically occur in much more minute ways than just changing the level of C++ standard support. Are you arguing that the final name of a Boost shared library should be different depending on its C++ standard support level ?
Yes, there are a lot more things that can cause the exact same problem -- this is one of the reasons why the Windows builds include so many different "ABI altering" flags in their names. Historically Linux hasn't had to worry about this as much since "everything" is compiled from source using the same compilers and libraries -- except when they aren't.