Re: [PATCH 00/19] Add hash table to gdbsupport

[John Baldwin <jhb@FreeBSD.org>]

On 1/11/24 10:07 AM, Tom Tromey wrote:
>>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:
> 
> [ new hash table ]
> 
> Tom> I'd like to move forward with this.
> 
> Tom> I think most of the patches here are straightforward.  The real question
> Tom> is whether we want it.  I've laid out my rationale in patch #1, with
> Tom> some additions (explaining why this is better than unordered_map /
> Tom> unordered_set) in a follow-up email.
> 
> I tried converting a few more libiberty hash tables to this one.
> 
> For a lot of things this is fine, big improvement, etc.
> 
> However, this hash table doesn't really admit the possibility that an
> element might not have a natural sentinel value.  This particularly
> comes up with hash maps, where if you want a std::string->whatever map,
> you have to introduce some kind of explicit sentinel (in my case I chose
> empty string) and also then have to write a trait class.
> 
> So, this is one area where unordered_map has the advantage.  Now, it
> would be possible to handle this in some way.  The hash table could
> store a sentinel flag, for instance.  Or, we could just accept this
> drawback and use unordered_map when convenience is important.> 
> Anyway, I tend to think it's not an enormous issue, but I figured I'd
> point it out.

This seems fine to me.

-- 
John Baldwin