C++ Logo

std-proposals

Advanced search

Re: [std-proposals] ABI breaks

From: Sebastian Wittmeier <wittmeier_at_[hidden]>
Date: Mon, 9 Jun 2025 15:06:53 +0200
Another option to correct it without ABI incompatibilities is to offer a std2 or a std::map2.   -----Ursprüngliche Nachricht----- Von:Ville Voutilainen via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 09.06.2025 15:04 Betreff:Re: [std-proposals] ABI breaks An:Avi Kivity <avi_at_[hidden]>; CC:Ville Voutilainen <ville.voutilainen_at_[hidden]>; std-proposals_at_[hidden]; On Mon, 9 Jun 2025 at 14:17, Avi Kivity <avi_at_[hidden]> wrote: > The Standard should not make decisions that cannot be implemented. But it also should not refrain from making decisions that cannot be implemented optimally on every platform, and instead leave it to the platform to make a choice. Well, that leads to this question: would you like it to be portably reliable that destroying a vector<optional<vector<optional<string>>>> is fast, or would you like it to be theoretically but not practically fast? You can get the first part without such problems if you bite the bullet and make it a separate type. But that might not work, of course, because the committee might not want it. You could try the second part, but that's then not portable because some vendors might not want it, and chances are that none of them want it, so it's portable in the sense that no practical implementation provides it. I'm not dismissing the idea, I love it; if I had a time machine, I'd travel back in time and incorporate such a "cheap to default-construct, so do that instead of constructing nothing" into optional's design. But it's quite a different exercise to try to adapt it in afterwards. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2025-06-09 13:15:07