From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2023-11-29 23:30:51
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
>> `<system_error>` or initialiser lists where the defects were not obvious
>> initially. `<regex>` and `<unordered_map>` 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