On 05/08/2019 23:13, Matt Bentley via SG14 wrote:
> On 2/08/2019 9:58 PM, Niall Douglas via SG14 wrote:
>> On 01/08/2019 22:50, Matt Bentley via SG14 wrote:
>> I'll be blunt here.
>>
>> I remain very unconvinced that any of the alt-containers which have
>> landed before WG21 in recent years are worth the committee time. I even
>> don't think Abseil's or Folly's containers are worth the committee time,
>> for the cost-benefits they supply.
>>
>> I would observe that a lot of what committee folk do nowadays in their
>> day jobs is write custom containers for bespoke use cases - indeed, just
>> last week I wrote yet another open addressed hash table.
>
> I get what you mean btw? From my perspective though, the SG14 containers
> aren't to replace custom-made solutions - they're for the many, many
> programmers who don't care about nth-degree performance but are trying
> to get code working, and end up re-implementing the wheel in very
> suboptimal ways. For example, there's a lot of cases I get anecdotes
> about where people need stable pointers so they end up using std::list
> or std::map - neither of which are good for that purpose alone.
>
> Colony fills that gap, and also the gap where people are implementing a
> form of bucket array in suboptimal ways, for example, using a bool as
> part of a struct to signify erasure.

I am keen that you keep doing what you're doing. And Zach with his open
hash table, and everybody else.

It's just that for me personally, I think C++ containers can be
radically different from what we have right now, and in a game changing way.

For example, in the open hash table I was recently working upon, we
handle capacity expansion by keeping two tables, and spending no more
than 1 microsecond moving items from the old table into the new table,
per trade packet. There is no dynamic memory allocation, we exclusively
use commit-on-first-write page allocation, which costs 400 - 1000 CPU
cycles per page fault.

We thus can implement semi-stable pointers and semi-stable references
using smart pointers and proxies. These basically self-refresh if they
become invalid, so they appear stable.

What I'd love is if we had built-in language support for semi-stable
iterators, pointers and references. Then nobody could accidentally take
a simple reference or a C pointer and cause it to dangle. Moreover, I
think this is doable without Rust-like annotation at the syntax level,
we just need an attribute like [[nodiscard]].

But I suppose I'm just dreaming now. Anyway, the point I'm trying to
make is that I think we can think much bigger wrt containers.
Fundamentally rethink what a container is, how it works, and the
guarantees it provides. Proposals for that kind of stuff before WG21
would get me very excited, even if I completely disagree with them. For
me, it's the right direction of travel.

Niall