Was the ABI break between 14.1 and 14.2 in std::_Hash and derived containers intentional?

[jake-at-work]

I am working with a library that uses std::unordered_map and std::unordered_set in its exported API. The library is compiled with VC 14.16. When an application compiled with 14.29 is linked to this library the linker fails to resolve std::_Hash::_Insert_new_node_before, which exists in the 14.29 xhash header but not in 14.16.

Is this ABI breaking change intentional?

Aside from not using any STL containers in a library API, is there some known workaround for this where we could continue to compile the library with 14.16 and applications with 14.29? We can break our ABI if necessary but not our API at this point.

Do the ABI stability and compatibility guarantees in VC 14.x extend to the STL included with these versions?

Thanks,
Jake

[fsb4000]

Hm, I'm not sure. It might be intentional...
I think maintainers care about backward compatibility, not forward compatibility.

P.S. I gave a link to this question on Discord, maybe it will speed up the answer from maintainers

[jake-at-work]

P.S. I gave a link to this question on Discord, maybe it will speed up the answer from maintainers

Should I take this conversation to Discord?

[fsb4000]

Sure, you can join: https://discord.gg/VS5Sd2wS

I think it will be a faster than waiting for a response on github. But they also respond at github.

[StephanTLavavej]

This is by design, but @CaseyCarter will update our documentation to explain why dllexporting classes derived from STL types is unsupported. Keeping this issue open until then.