Take unordered_map<>, that's ten times more comfortable than any C
solution.
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.
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.
E. Compilation time. Slow.
Could not be a problem when unordered_map used in just few compilation
units. Could be serious problem otherwise.
Am 10.04.2026 um 12:13 schrieb Michael S:t
On the other hand, it's harder work. Exact requirements for Hash are no
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.
Am 10.04.2026 um 12:13 schrieb Michael S:t
On the other hand, it's harder work. Exact requirements for Hash are no
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.
I doubt that.
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.
Your C++ (and c++ std-lib) is basically a macro language, ...
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;
ystemClib has a principle (me thinks): Clib only contains those that app. (s
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 ...
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 should ask what C++ (std library) provides that no app. codes can.
Am 10.04.2026 um 15:11 schrieb wij:lf.
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 yourse
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.
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.
I guess std::unordered_map won't be 'very large', because I implemented a red-black tree class. ...
Like all kinds of input/output format problem, you don't need a 'language' suits you need, just write your own conversions.
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 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.
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.
Am 10.04.2026 um 16:35 schrieb wij:
aI guess std::unordered_map won't be 'very large', because I implemented
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.
ge'Like all kinds of input/output format problem, you don't need a 'langua
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.
s thatI am afraid this is illusion. C++ std library has lots of man-made rule
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.
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.
On Fri, 2026-04-10 at 17:07 +0200, Bonita Montero wrote:
Am 10.04.2026 um 16:35 schrieb wij:a
=20
=20
I guess std::unordered_map won't be 'very large', because I implemented=
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 just mention a point: What does it mean "incrementing pointers" in C++ ???
It seems you are talking about ideal.
If so simple,easy,powerful, why many programmers (esp. beginners) avoid C++,
...
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 incrementingC++,
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
...
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.
Am 10.04.2026 um 19:40 schrieb wij:low level,
C++ provides 'illusions' (simple/fast/elegant..), you need to know the
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.
n orAll programming have to be converted to machine codes. Human abstractio
assideal has no position in CPU's eye (so far, no computing model can surp
ot C++.Turing Machine). Some languages can simply its programming model, but n
C++ provides a near optimal timing
although the runtime is abstracted.
The only deviation from that are exceptions.
theDoing so (making C++ high level language) might be possible, but not in
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.
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.
What is "runtime is abstracted" ?
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++.
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.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 15 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 180:25:01 |
| Calls: | 213 |
| Files: | 21,502 |
| Messages: | 84,274 |