3 ms·
Also, I hope that if you’re reading this post in a year or two (say, December 2025), these specific examples won’t even reproduce anymore. I hope libstdc++ gets
by leni536 2y ago
Also, I hope that if you’re reading this post in a year or two (say, December 2025), these specific examples won’t even reproduce anymore. I hope libstdc++ gets on the ball and eliminates some of this weirdness. (In short: They should get rid of the blacklist; pay the 8 bytes by default; introduce a whitelist for trivial hashers specifically; stop checking noexceptness for any reason.)
I think this would be an ABI break.
- davisp 2y agoProbably so! Although, given that C++ doesn’t have ABI contracts to begin with, I’m not sure how it would matter in practice.
- Iwan-Zotow 2y agoPlatforms have ABIs
- leni536 2y agoAll three of the major C++ standard library implementations have stable ABI contracts.
- quuxplusone 2y agoFWIW: I've had your comment at the back of my mind for the past 5 days, and I haven't yet come up with any clever way to work around it. I think you're simply right: to "fix" this in "new code" would break ABI for anyone who passed e.g. `vector<unordered_set<T>>` across an ABI boundary. (I.e., anywhere that "new code" might construct an unordered_set object according to the "new ABI," which object might later be destroyed by "old code" which assumed the "old ABI," leading to heap corruption.) So yeah, it is probably physically impossible for libstdc++ to "get on the ball" in the way I'd hoped. Darn.