Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #123690 > unrolled thread

Re: A neat hash table implementation

Back to article view | Back to comp.lang.c++

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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
      Re: A neat hash table implementation wij <wyniijj5@gmail.com> - 2026-04-10 19:50 +0800
        Re: A neat hash table implementation Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-10 14:34 +0200
          Re: A neat hash table implementation wij <wyniijj5@gmail.com> - 2026-04-10 21:11 +0800
            Re: A neat hash table implementation Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-10 15:19 +0200
              Re: A neat hash table implementation wij <wyniijj5@gmail.com> - 2026-04-10 22:35 +0800
                Re: A neat hash table implementation Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-10 17:07 +0200
                  Re: A neat hash table implementation wij <wyniijj5@gmail.com> - 2026-04-11 00:16 +0800
                    Re: A neat hash table implementation scott@slp53.sl.home (Scott Lurndal) - 2026-04-10 16:30 +0000
                    Re: A neat hash table implementation Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-10 18:50 +0200
                      Re: A neat hash table implementation wij <wyniijj5@gmail.com> - 2026-04-11 01:40 +0800
                        Re: A neat hash table implementation Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-11 08:26 +0200
                          Re: A neat hash table implementation wij <wyniijj5@gmail.com> - 2026-04-11 20:09 +0800
                            Re: A neat hash table implementation Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-11 14:29 +0200
                Re: A neat hash table implementation Michael S <already5chosen@yahoo.com> - 2026-04-10 18:12 +0300
                  Re: A neat hash table implementation wij <wyniijj5@gmail.com> - 2026-04-11 00:26 +0800
          Re: A neat hash table implementation 🇵🇱Jacek Marcin Jaworski🇵🇱 <jmj@energokod.gda.pl> - 2026-04-10 16:38 +0200
            Re: A neat hash table implementation Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-10 17:08 +0200
      Re: A neat hash table implementation wij <wyniijj5@gmail.com> - 2026-04-10 19:51 +0800

#123690 — Re: A neat hash table implementation

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.

[toc] | [next] | [standalone]

#123691

Am 10.04.2026 um 12:13 schrieb Michael S:

> 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.

Most hashers are 5min of work.

> 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.

Maybe that was before C++17. Today I'd use a string_view.

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

I'm using a compiler which supports C++20 modules.
With that compile times are a magnitude lower.

[toc] | [prev] | [next] | [standalone]

#123692

On Fri, 2026-04-10 at 13:07 +0200, Bonita Montero wrote:
> Am 10.04.2026 um 12:13 schrieb Michael S:
> 
> > 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.
> 
> Most hashers are 5min of work.

I doubt that.

> > 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.
> 
> Maybe that was before C++17. Today I'd use a string_view.
> 
> > E. Compilation time. Slow.
> > Could not be a problem when unordered_map used in just few compilation
> > units. Could be serious problem otherwise.
> 
> I'm using a compiler which supports C++20 modules.
> With that compile times are a magnitude lower.

Clib has a principle (me thinks): Clib only contains those that app. (system
utilities, strictly) cannot do without.... So, basically, 'unbeatable'.
Many of your 'better implement' are false.

hsearch(3) is a special case in that it is 'too fast', so fast to out-weight
other deficiency.

Your C++ (and c++ std-lib) is basically a macro language,  Many things can
be done between the final code (say assembly) and the user's code, not 
necessarily in c++'s type system (language), kind of description.

[toc] | [prev] | [next] | [standalone]

#123694

Am 10.04.2026 um 13:50 schrieb wij:

> I doubt that.

You're right, this was 2min of work:

struct Key
{
	string s;
	int i;
	float f;
};

template<>
struct std::hash<Key>
{
	size_t operator ()( const Key &ky ) const noexcept
	{
		return hash<string>()( ky.s )
			^ hash<int>()( ky.i )
			^ hash<float>()( ky.f );
	}
};

...
unordered_map<Key, int> umki;


> Clib has a principle (me thinks): Clib only contains those that app. (system
> utilities, strictly) cannot do without.... So, basically, 'unbeatable'.
> Many of your 'better implement' are false.

With C++ you write a fifth of the code you'd write in C.
That isn't outweighed by the compilations times, even
more not when you use modules.

> Your C++ (and c++ std-lib) is basically a macro language, ...

That's naive. Try that you can do with C++ containers
f.e. unordered_map<K, V> with macros ...

[toc] | [prev] | [next] | [standalone]

#123695

On Fri, 2026-04-10 at 14:34 +0200, Bonita Montero wrote:
> Am 10.04.2026 um 13:50 schrieb wij:
> 
> > I doubt that.
> 
> You're right, this was 2min of work:
> 
> struct Key
> {
> 	string s;
> 	int i;
> 	float f;
> };
> 
> template<>
> struct std::hash<Key>
> {
> 	size_t operator ()( const Key &ky ) const noexcept
> 	{
> 		return hash<string>()( ky.s )
> 			^ hash<int>()( ky.i )
> 			^ hash<float>()( ky.f );
> 	}
> };
> 
> ...
> unordered_map<Key, int> umki;

Whenever you want to SEE a 'short and becautiful' case of usage, there will be 
one, you just write the library in the background for it yourself.

> > Clib has a principle (me thinks): Clib only contains those that app. (system
> > utilities, strictly) cannot do without.... So, basically, 'unbeatable'.
> > Many of your 'better implement' are false.
> 
> With C++ you write a fifth of the code you'd write in C.
> That isn't outweighed by the compilations times, even
> more not when you use modules.
> 
> > Your C++ (and c++ std-lib) is basically a macro language, ...
> 
> That's naive. Try that you can do with C++ containers
> f.e. unordered_map<K, V> with macros ...

You should ask what C++ (std library) provides that no app. codes can.

[toc] | [prev] | [next] | [standalone]

#123696

Am 10.04.2026 um 15:11 schrieb wij:

> Whenever you want to SEE a 'short and becautiful' case of usage, there
> will be one, you just write the library in the background for it yourself.

You see the details withot the whole picture. unordered_map is a
very large class. Although there might be some work for the hasher
it saves really much time over C.

> You should ask what C++ (std library) provides that no app. codes can.

Nothing, but with C++ you don't need to write everything on your own.
With C you need to flip every bit yourself.

[toc] | [prev] | [next] | [standalone]

#123697

On Fri, 2026-04-10 at 15:19 +0200, Bonita Montero wrote:
> Am 10.04.2026 um 15:11 schrieb wij:
> 
> > Whenever you want to SEE a 'short and becautiful' case of usage, there
> > will be one, you just write the library in the background for it yourself.
> 
> You see the details withot the whole picture. unordered_map is a
> very large class. Although there might be some work for the hasher
> it saves really much time over C.

I guess std::unordered_map won't be 'very large', because I implemented a 
red-black tree class. But I don't know hash algorithm, instead I wrap
hsearch. hsearch is fast, I think I can convert real usage to use hsearch.
Like all kinds of input/output format problem, you don't need a 'language'
suits you need, just write your own conversions.

A main consideration is that speed and memory consumption are ultimately 
the same thing. 

> > You should ask what C++ (std library) provides that no app. codes can.
> 
> Nothing, but with C++ you don't need to write everything on your own.

I am afraid this is illusion. C++ std library has lots of man-made rules that
are difficult to deduce other properties. C is a (necessary) part of C++, 
you cannot avoid learning low level stuff to understand C++ properly.
And I found many C++ programmers just 'know' C++'s rules but not the basic
reality of computation. Why bother on words-on-words stuff.

> With C you need to flip every bit yourself.

That is true, but there are good and bad (e.g. when your PC panic, not rare).

[toc] | [prev] | [next] | [standalone]

#123699

Am 10.04.2026 um 16:35 schrieb wij:


> I guess std::unordered_map won't be 'very large', because I implemented a
> red-black tree class. ...

It's not very large since you've implemented sth. different ?
unordered_map has more than 50 methods, a lot of constructors and a
forward iterator; that's a lot of work. Because of the latter itera-
ting through the map is just like incrementing pointers.

> Like all kinds of input/output format problem, you don't need a 'language'
> suits you need, just write your own conversions.

For systems programming a lanugage that is fast and doesn't need much
effort to handle is most appropriate.

> I am afraid this is illusion. C++ std library has lots of man-made rules that
> are difficult to deduce other properties.


I think what the standard library does is quite transparent. Very few
classes are inherently complex due to their data structure and therefore
simple; rather, it's the large number of methods that ultimately make
things easier.

> C is a (necessary) part of C++, you cannot avoid learning low level
> stuff to understand C++ properly.

Nevertheless programming in C++ is much more different. You can do
things like in C but that's more bug-prone and you'd write multiple
times the code.

> And I found many C++ programmers just 'know' C++'s rules but not
> the basic reality of computation. Why bother on words-on-words stuff.

There might be such developers but when I look at the vids of CppCon
or Jason Turner (C++ Weekly) on YouTube I get the impression that C++
is the language where the developers can handle both the  and the
highlevel part.

[toc] | [prev] | [next] | [standalone]

#123702

On Fri, 2026-04-10 at 17:07 +0200, Bonita Montero wrote:
> Am 10.04.2026 um 16:35 schrieb wij:
> 
> 
> > I guess std::unordered_map won't be 'very large', because I implemented a
> > red-black tree class. ...
> 
> It's not very large since you've implemented sth. different ?
> unordered_map has more than 50 methods, a lot of constructors and a
> forward iterator; that's a lot of work. Because of the latter itera-
> ting through the map is just like incrementing pointers.

I just mention a point: What does it mean "incrementing pointers" in C++ ???

> > Like all kinds of input/output format problem, you don't need a 'language'
> > suits you need, just write your own conversions.
> 
> For systems programming a lanugage that is fast and doesn't need much
> effort to handle is most appropriate.

It seems you are talking about ideal.

> > I am afraid this is illusion. C++ std library has lots of man-made rules that
> > are difficult to deduce other properties.
> 
> 
> I think what the standard library does is quite transparent. Very few
> classes are inherently complex due to their data structure and therefore
> simple; rather, it's the large number of methods that ultimately make
> things easier.

If so simple,easy,powerful, why many programmers (esp. beginners) avoid C++,
even it is difficult to discuss right on the point on comp.lang.c++?
And I had difficulty reading your codes?

> > C is a (necessary) part of C++, you cannot avoid learning low level
> > stuff to understand C++ properly.
> 
> Nevertheless programming in C++ is much more different. You can do
> things like in C but that's more bug-prone and you'd write multiple
> times the code.
> 
> > And I found many C++ programmers just 'know' C++'s rules but not
> > the basic reality of computation. Why bother on words-on-words stuff.
> 
> There might be such developers but when I look at the vids of CppCon
> or Jason Turner (C++ Weekly) on YouTube I get the impression that C++
> is the language where the developers can handle both the  and the
> highlevel part.

I feel, you just want to say C++ is great. Yes, it is, but not what most
used to though.

[toc] | [prev] | [next] | [standalone]

#123704

wij <wyniijj5@gmail.com> writes:
>On Fri, 2026-04-10 at 17:07 +0200, Bonita Montero wrote:
>> Am 10.04.2026 um 16:35 schrieb wij:
>>=20
>>=20
>> > I guess std::unordered_map won't be 'very large', because I implemented=
> a
>> > red-black tree class. ...
>>=20
>> It's not very large since you've implemented sth. different ?
>> unordered_map has more than 50 methods, a lot of constructors and a
>> forward iterator; that's a lot of work. Because of the latter itera-
>> ting through the map is just like incrementing pointers.
>
>I just mention a point: What does it mean "incrementing pointers" in C++ ??=

I would expect that means that the map appears to be a contiguous
array of elements, so incrementing a pointer to element A will result
in a pointer to element A+1.   Perhaps by overloading operator++ in
the map.

[toc] | [prev] | [next] | [standalone]

#123705

Am 10.04.2026 um 18:16 schrieb wij:

> I just mention a point: What does it mean "incrementing pointers" in C++ ???

Going through an unordered_map with iterator is similar to incrementing
a pointer.

> It seems you are talking about ideal.

C++ is closer to that than C.

> If so simple,easy,powerful, why many programmers (esp. beginners) avoid C++,
 > ...

There are a lot of developers with a minimalism mindeset. Being focussed
on details is an attitude you must have as a developer, but if you're
only on this level like a lot of passioned C developers, you make a big
mistake since you don't see the opportunties the abstaction levels above
in C++ provide.

[toc] | [prev] | [next] | [standalone]

#123706

On Fri, 2026-04-10 at 18:50 +0200, Bonita Montero wrote:
> Am 10.04.2026 um 18:16 schrieb wij:
> 
> > I just mention a point: What does it mean "incrementing pointers" in C++ ???
> 
> Going through an unordered_map with iterator is similar to incrementing
> a pointer.
> 
> > It seems you are talking about ideal.
> 
> C++ is closer to that than C.
> 
> > If so simple,easy,powerful, why many programmers (esp. beginners) avoid C++,
>  > ...
> 
> There are a lot of developers with a minimalism mindeset. Being focussed
> on details is an attitude you must have as a developer, but if you're
> only on this level like a lot of passioned C developers, you make a big
> mistake since you don't see the opportunties the abstaction levels above
> in C++ provide.

C++ provides 'illusions' (simple/fast/elegant..), you need to know the low level,
hardware events to harness it, or there are 'surprises'.

All programming have to be converted to machine codes. Human abstraction or 
ideal has no position in CPU's eye (so far, no computing model can surpass
Turing Machine). Some languages can simply its programming model, but not C++.

Doing so (making C++ high level language) might be possible, but not in the
programs you have shown. Your code is immature.

[toc] | [prev] | [next] | [standalone]

#123707

Am 10.04.2026 um 19:40 schrieb wij:

> C++ provides 'illusions' (simple/fast/elegant..), you need to know the low level,
> hardware events to harness it, or there are 'surprises'.

Depends on what you do. If you have to write "algorithmic" in a more
narrow sense you're 50% closer to what you do in C and you need the
same skills. But if you apply C++ runtime for that you don't need
that.

> All programming have to be converted to machine codes. Human abstraction or
> ideal has no position in CPU's eye (so far, no computing model can surpass
> Turing Machine). Some languages can simply its programming model, but not C++.

C++ provides a near optimal timing although the runtime is abstracted.
The only deviation from that are exceptions.

> Doing so (making C++ high level language) might be possible, but not in the
> programs you have shown. Your code is immature.

Absolutely not, it's just because you can't handle abstractions.
You want to flip every bit yourself; that's a personality weakness
a lot of C developers have.

[toc] | [prev] | [next] | [standalone]

#123709

On Sat, 2026-04-11 at 08:26 +0200, Bonita Montero wrote:
> Am 10.04.2026 um 19:40 schrieb wij:
> 
> > C++ provides 'illusions' (simple/fast/elegant..), you need to know the low level,
> > hardware events to harness it, or there are 'surprises'.
> 
> Depends on what you do. If you have to write "algorithmic" in a more
> narrow sense you're 50% closer to what you do in C and you need the
> same skills. But if you apply C++ runtime for that you don't need
> that.

I cannot figure out what point you are really aiming at. But, if I guess 
you mean "C++ is good in expressing algorithm".... In short, there are too
many 'non-ideal' details.

> > All programming have to be converted to machine codes. Human abstraction or
> > ideal has no position in CPU's eye (so far, no computing model can surpass
> > Turing Machine). Some languages can simply its programming model, but not C++.
> 
> C++ provides a near optimal timing

Hardware timing? optimal?

> although the runtime is abstracted.

What is "runtime is abstracted" ?

> The only deviation from that are exceptions.

I think you are talking about API. I can tell you one of the worst thing of C++.
The development of C++ language had never thought of (std-library) API, all are 
user's imagination.

By the way, I think std::exception is another bad thing of C++.

> > Doing so (making C++ high level language) might be possible, but not in the
> > programs you have shown. Your code is immature.
> 
> Absolutely not, it's just because you can't handle abstractions.
> You want to flip every bit yourself; that's a personality weakness
> a lot of C developers have.

Actually, half of my time now is devoted to theoretical abstraction. There is
no clue you understand the basic of computation and algorithmics, but psychological 
reaction to comfort yourself.

[toc] | [prev] | [next] | [standalone]

#123710

Am 11.04.2026 um 14:09 schrieb wij:


> I cannot figure out what point you are really aiming at. But, if I guess
> you mean "C++ is good in expressing algorithm".... In short, there are too
> many 'non-ideal' details.

I referred to the abstractions C++ has. If you use them through your
runtime you'va a fraction of the code you'd have in C; and the code
is nearly optimal in terms of performance.
But if you're writing the algorithms themselfes the code is similar
to C.

> What is "runtime is abstracted" ?

You don't see the algorithms the C++ runtime uses.

> I think you are talking about API. I can tell you one of the worst thing of C++.
> The development of C++ language had never thought of (std-library) API, all are
> user's imagination.

STL implements common data structures and the code is optimal in terms
of performance.

> By the way, I think std::exception is another bad thing of C++.

It's slow, which doesn't matter since error-handling doesn't have to
be fast. But it's much more convenient than dealing wih return codes
like in C.

> Actually, half of my time now is devoted to theoretical abstraction.

Have a look at the performance constraints with the mapping containers
then you see what I mean with abstraction.

> There is no clue you understand the basic of computation and algorithmics,
> but psychological reaction to comfort yourself.

There are much more sick C users than C++ users.

[toc] | [prev] | [next] | [standalone]

#123701

On Fri, 10 Apr 2026 22:35:52 +0800
wij <wyniijj5@gmail.com> wrote:

> On Fri, 2026-04-10 at 15:19 +0200, Bonita Montero wrote:
> > Am 10.04.2026 um 15:11 schrieb wij:
> >   
> > > Whenever you want to SEE a 'short and becautiful' case of usage,
> > > there will be one, you just write the library in the background
> > > for it yourself.  
> > 
> > You see the details withot the whole picture. unordered_map is a
> > very large class. Although there might be some work for the hasher
> > it saves really much time over C.  
> 
> I guess std::unordered_map won't be 'very large', because I
> implemented a red-black tree class.

red-black tree is at core of std::map.
It is unrelated to std::unordered_map.

[toc] | [prev] | [next] | [standalone]

#123703

On Fri, 2026-04-10 at 18:12 +0300, Michael S wrote:
> On Fri, 10 Apr 2026 22:35:52 +0800
> wij <wyniijj5@gmail.com> wrote:
> 
> > On Fri, 2026-04-10 at 15:19 +0200, Bonita Montero wrote:
> > > Am 10.04.2026 um 15:11 schrieb wij:
> > >   
> > > > Whenever you want to SEE a 'short and becautiful' case of usage,
> > > > there will be one, you just write the library in the background
> > > > for it yourself.  
> > > 
> > > You see the details withot the whole picture. unordered_map is a
> > > very large class. Although there might be some work for the hasher
> > > it saves really much time over C.  
> > 
> > I guess std::unordered_map won't be 'very large', because I
> > implemented a red-black tree class.
> 
> red-black tree is at core of std::map.
> It is unrelated to std::unordered_map.

Thanks. But, I think red-black tree is a bit complex but not very long. 
The algorithm for hash table should be not too different. Of course,
implement for every types in form of inputs might take up sizes.

[toc] | [prev] | [next] | [standalone]

#123698

W dniu 10.04.2026 o 14:34, Bonita Montero pisze:
>> Clib has a principle (me thinks): Clib only contains those that app. 
>> (system
>> utilities, strictly) cannot do without.... So, basically, 'unbeatable'.
>> Many of your 'better implement' are false.
> 
> With C++ you write a fifth of the code you'd write in C.

Please correct yourself:

"With PLAIN C++ you write a fifth of the code you'd write in PLAIN C."

But every modern industry is build on modular components. So it is 
normal, that all langs (not only C, C++ or D) require smart libs. in 
order to efficient programming. Smart libs can be written for C, C++ and 
even for D langs. This is challenge, not lang wars, which are like OS 
wars, and both are kind of religion wars, which are stupid and pure evil.

-- 
Jacek Marcin Jaworski,  Pruszcz Gd., woj. Pomorskie, Polska 🇵🇱, EU 🇪🇺;
tel.: +48-609-170-742,   najlepiej w godz.: 5:00-5:55 lub 16:00-17:25;
<jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW:                             <https://energokod.gda.pl>;
Mini Netykieta:         <https://energokod.gda.pl/MiniNetykieta.html>;
Mailowa Samoobrona:             <https://emailselfdefense.fsf.org/pl>.
UWAGA:
NIE ZACIĄGAJ "UKRYTEGO DŁUGU"! PŁAĆ ZA PROG. FOSS I INFO. INTERNETOWE!
CZYTAJ DARMOWY: "17. Raport Totaliztyczny - Patroni Kontra Bankierzy":
<https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>

[toc] | [prev] | [next] | [standalone]

#123700

Am 10.04.2026 um 16:38 schrieb 🇵🇱Jacek Marcin Jaworski🇵🇱:

> "With PLAIN C++ you write a fifth of the code you'd write in PLAIN C."

Right, I made a mistake. But there's plain C, but not plain C++ since
it's really a language with a lot of depth

> 
> But every modern industry is build on modular components. So it is 
> normal, that all langs (not only C, C++ or D) require smart libs. in 
> order to efficient programming. Smart libs can be written for C, C++ and 
> even for D langs. This is challenge, not lang wars, which are like OS 
> wars, and both are kind of religion wars, which are stupid and pure evil.
> 

[toc] | [prev] | [next] | [standalone]

#123693

On Fri, 2026-04-10 at 13:07 +0200, Bonita Montero wrote:
> Am 10.04.2026 um 12:13 schrieb Michael S:
> 
> > 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.
> 
> Most hashers are 5min of work.

I doubt that.

> > 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.
> 
> Maybe that was before C++17. Today I'd use a string_view.
> 
> > E. Compilation time. Slow.
> > Could not be a problem when unordered_map used in just few compilation
> > units. Could be serious problem otherwise.
> 
> I'm using a compiler which supports C++20 modules.
> With that compile times are a magnitude lower.

Clib has a principle (me thinks): Clib only contains those that app. (system
utilities, strictly) cannot do without.... So, basically, 'unbeatable'.
Many of your 'better implement' are false.

hsearch(3) is a special case in that it is 'too fast', so fast to out-weight
other deficiency.

Your C++ (and c++ std-lib) is basically a macro language,  Many things can
be done between the final code (say assembly) and the user's code, not 
necessarily in c++'s type system (language), kind of description.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web