Re: Boost vs Std library features

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