Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.lang.c > #397464

Re: A neat hash table implementation

Cross-posted to 2 groups.

Show all headers | View raw

On Fri, 10 Apr 2026 05:42:47 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:

> Take unordered_map<>, that's ten times more comfortable than any C
> solution.

First, your reply is mildly off topic in comp.lang.c.
Second, my reply is going to be even more off topic. Not that it stops
me. 
In order to remain partly on topic I'm cross-posting to comp.lang.c++

A. For most common cases I agree.

B. For less common cases, where standard library does not provide
ready-made hash function for your Key type, it is less clear.
On one hand, implementing only custom hash function (or functor) is less
work than implementing full associative array.
On the other hand, it's harder work. Exact requirements for Hash are not
specified in easy-to-read language. I don't know about you, but for me
personally it feels like going on mine field. 
So, personally, I'd rather code full associative array than Hash for
std::unordered_map<>. More work, but better feeling of control.

All that rather different from supplying comparison primitive for
std::map<> where interface and requirements are crystal clear and the
task itself is much simpler.

C. std::unordered_map<> can be surprising.
I think, it was you who showed us such case couple of years ago, when
you tried to use string literals as keys.

D. Performance.
For optimized "Release" build performance of std::unordered_map<> is
typically very good. But for non-optimized "Debug" build it typically
very bad. 
That's unlike C-style implementations in separately compiled library:
here performance is, may be, not quite as good as "Release" build of
std::unordered_map<>, but close. But it remains the same under
"Debug" build.

E. Compilation time. Slow. 
Could not be a problem when unordered_map used in just few compilation
units. Could be serious problem otherwise.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

A neat hash table implementation highcrew <high.crew3868@fastmail.com> - 2026-04-07 23:38 +0200
  Re: A neat hash table implementation 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-04-08 05:14 +0200
    Re: A neat hash table implementation highcrew <high.crew3868@fastmail.com> - 2026-04-08 09:29 +0200
    Re: A neat hash table implementation BGB <cr88192@gmail.com> - 2026-04-10 01:17 -0500
      Re: A neat hash table implementation Michael S <already5chosen@yahoo.com> - 2026-04-10 13:25 +0300
        Re: A neat hash table implementation BGB <cr88192@gmail.com> - 2026-04-10 13:00 -0500
          Re: A neat hash table implementation James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-10 17:31 -0400
            Re: A neat hash table implementation BGB <cr88192@gmail.com> - 2026-04-10 23:34 -0500
              Re: A neat hash table implementation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-11 08:20 +0200
                Re: A neat hash table implementation BGB <cr88192@gmail.com> - 2026-04-11 04:19 -0500
              Re: A neat hash table implementation Michael S <already5chosen@yahoo.com> - 2026-04-11 20:28 +0300
          Re: A neat hash table implementation HashTables <invalid@invalid.invalid> - 2026-04-11 20:06 +0100
            Re: A neat hash table implementation Michael S <already5chosen@yahoo.com> - 2026-04-12 11:06 +0300
              Re: A neat hash table implementation BGB <cr88192@gmail.com> - 2026-04-12 04:24 -0500
              Re: A neat hash table implementation HashTables <invalid@invalid.invalid> - 2026-04-12 19:56 +0100
            Re: A neat hash table implementation Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-13 08:27 -0700
              Re: A neat hash table implementation BGB <cr88192@gmail.com> - 2026-04-13 14:46 -0500
                Re: A neat hash table implementation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-14 01:14 +0200
              Re: A neat hash table implementation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-13 14:42 -0700
                Re: A neat hash table implementation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-14 01:17 +0200
          Re: A neat hash table implementation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-11 14:19 -0700
            Re: A neat hash table implementation BGB <cr88192@gmail.com> - 2026-04-12 03:36 -0500
        Re: A neat hash table implementation Bart <bc@freeuk.com> - 2026-04-10 21:07 +0100
          Re: A neat hash table implementation BGB <cr88192@gmail.com> - 2026-04-10 16:13 -0500
        Re: A neat hash table implementation antispam@fricas.org (Waldek Hebisch) - 2026-04-12 14:51 +0000
  Re: A neat hash table implementation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-08 10:42 +0200
    Re: A neat hash table implementation highcrew <high.crew3868@fastmail.com> - 2026-04-08 21:44 +0200
      Re: A neat hash table implementation makendo <makendo@makendo.invalid> - 2026-04-10 10:40 +0800
  Re: A neat hash table implementation Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-10 05:42 +0200
    Re: A neat hash table implementation Michael S <already5chosen@yahoo.com> - 2026-04-10 13:13 +0300
      Re: A neat hash table implementation Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-10 13:07 +0200

csiph-web