On 29/11/2023 22:20, Andrey Semashev via Boost wrote:
On 11/30/23 01:03, Niall Douglas via Boost wrote:
There were still some big design mistakes in 11 - I still find `<random>` very unfortunate and entirely avoidable at the time, unlike `
` or initialiser lists where the defects were not obvious initially. `<regex>` and ` ` probably couldn't have been predicted easily in advance, at their time they seemed reasonable. Could you elaborate on the design problems of the above components?
One could write a book on them, so I shall have to be terse.
Or perhaps, you have a link where these problems are described? I'm interested in initializer lists, regex and unordered_map in particular.
Initialiser lists don't initialise in reliable ways. I think Arthur and others did a bunch of blog posts about it. They also didn't initially cope well with static const runtime representations, which has since been partially fixed, but what we've ended up with is far from what they should have been had they been thought through better. They also have weird quirks in what they can deduce without being hinted at, and what they can't. And finally, compilers are really, really slow when fed large initialiser lists, I was told once that's because they mandate O(N^2) complexity which was surely foreseeable. Regex is templates based, and anything templates based has horrible ABI consequences if you cannot break ABI. You can't safely standardise something templates based without getting it absolutely 100% right from the beginning, and as any user of std::regex will testify, we did not. You'd think we would have learned from that, but no we keep standardising large templates based things and then experiencing the same kiss of death by ABI. So not only was that foreseeable, but we are still repeating the same. Unordered_map gives stronger guarantees than it needs to for 99% of code, and that makes it slow. Slightly relaxing its guarantees would have avoided that problem entirely, and still kept iterator stability etc. That was surely foreseeable. Obviously all the above is much easier with hindsight. However, having been on the committee for five years I have again and again and again seen somebody who really knows what they're talking about warn of consequences down the line, it might avoid a bad decision that meeting but next meeting they forget and that person isn't in the room that time and so it gets changed for the worse. I don't know if the same happened for all those facilities above, but I would suspect it did from everything I've seen. The problem with consensus based decision making is some people really ought to have 10x the votes of anybody else, but if they fail to persuade the room on the day or are in a different room, then bad decisions get taken. I can't speak of details of a specific meeting (ISO rules), but a formative moment for me was when discussing a small but key new feature in the C++ 23 standard. We had three standard library implementers in the room who pleaded for a certain stronger guarantee in the design, along with all of the Boost crowd, and yet we couldn't persuade the room so there was no consensus for change. Two weeks ago at work I had to completely reimplement from scratch that standard library feature in order to ensure that stronger guarantee because the standard library one does not. I was thinking ruefully of that day in WG21, wondering what the hell am I doing there? I don't think I'm making the world a better place by directing my energies at there, anyway. Niall