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

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

"Performance of C++20's Ranges"

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

Contents

  "Performance of C++20's Ranges" Cholo Lennon <chololennon@hotmail.com> - 2022-04-26 01:13 -0300
    Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-26 09:15 +0000
      Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-04-26 09:27 +0000
        Re: "Performance of C++20's Ranges" Manfred <noname@add.invalid> - 2022-04-26 16:29 +0200
          Re: "Performance of C++20's Ranges" "Ross A. Finlayson" <ross.finlayson@gmail.com> - 2022-05-01 18:45 -0700
      Re: "Performance of C++20's Ranges" "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-04-26 11:42 +0200
        Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-04-26 11:11 +0000
          Re: "Performance of C++20's Ranges" "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-04-26 13:31 +0200
          Re: "Performance of C++20's Ranges" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-26 06:46 -0700
          Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-27 08:20 +0000
            Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-04-27 08:40 +0000
              Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-27 15:12 +0000
                Re: "Performance of C++20's Ranges" scott@slp53.sl.home (Scott Lurndal) - 2022-04-27 16:09 +0000
                  Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-27 16:21 +0000
                    Re: "Performance of C++20's Ranges" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-29 16:15 -0700
                      Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-30 16:00 +0000
              Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-27 19:03 +0200
            Re: "Performance of C++20's Ranges" James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-27 11:12 -0400
              Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-04-28 06:45 +0000
        Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-04-27 06:30 +0000
          Re: "Performance of C++20's Ranges" Manfred <noname@add.invalid> - 2022-04-28 23:57 +0200
            Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-04-29 06:07 +0000
          Re: "Performance of C++20's Ranges" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-29 16:28 -0700
            Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-05-02 05:01 +0000
              Re: "Performance of C++20's Ranges" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-10 07:36 -0700
      Re: "Performance of C++20's Ranges" James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-26 11:28 -0400
        Re: "Performance of C++20's Ranges" Manfred <noname@add.invalid> - 2022-04-26 18:13 +0200
        Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-26 16:24 +0000
          Re: "Performance of C++20's Ranges" James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-26 12:48 -0400
      Re: "Performance of C++20's Ranges" Cholo Lennon <chololennon@hotmail.com> - 2022-04-26 20:20 -0300
        Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-27 08:30 +0000
          Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-04-27 08:50 +0000
            Re: "Performance of C++20's Ranges" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-27 05:12 -0700
            Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-27 15:18 +0000
              Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-27 18:56 +0200
                Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 08:40 +0000
                  Re: "Performance of C++20's Ranges" Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-28 13:54 +0300
                    Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 13:11 +0200
                      Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:25 +0000
                        Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 17:30 +0200
                          Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:45 +0000
                            Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 17:52 +0200
                              Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:57 +0000
                                Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 18:01 +0200
                                  Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 16:06 +0000
                                    Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 18:09 +0200
                                      Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 16:14 +0000
                        Re: "Performance of C++20's Ranges" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-04-28 16:11 -0700
                          Re: "Performance of C++20's Ranges" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-04-28 16:20 -0700
                          Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-29 09:31 +0000
                    Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:15 +0000
                  Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 13:07 +0200
                    Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:17 +0000
                      Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 17:31 +0200
                        Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:50 +0000
                          Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 17:55 +0200
                            Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:59 +0000
                              Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 18:02 +0200
                                Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 16:13 +0000
                                  Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 18:20 +0200
                                    Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-29 09:27 +0000
                                      Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-29 20:48 +0200
                                      Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-30 07:34 +0200
                                        Re: "Performance of C++20's Ranges" scott@slp53.sl.home (Scott Lurndal) - 2022-04-30 17:31 +0000
                                          Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-30 20:30 +0200
                                          Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-05-01 15:20 +0000
                                            Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-01 18:18 +0200
                                              Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-05-01 16:25 +0000
                                            Re: "Performance of C++20's Ranges" scott@slp53.sl.home (Scott Lurndal) - 2022-05-01 23:14 +0000
                                Re: "Performance of C++20's Ranges" "Ross A. Finlayson" <ross.finlayson@gmail.com> - 2022-05-01 18:52 -0700
                              Re: "Performance of C++20's Ranges" scott@slp53.sl.home (Scott Lurndal) - 2022-04-28 18:21 +0000
                                Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-29 09:29 +0000
                            Re: "Performance of C++20's Ranges" scott@slp53.sl.home (Scott Lurndal) - 2022-04-28 18:19 +0000
                              Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 21:01 +0200
                      Re: "Performance of C++20's Ranges" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-04-28 16:07 -0700
                    Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:22 +0000
              Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-04-28 10:57 +0000
                Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:27 +0000
                Re: "Performance of C++20's Ranges" red floyd <no.spam.here@its.invalid> - 2022-04-28 09:26 -0700
          Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-27 17:07 +0200
            Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-27 15:54 +0000
              Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-27 18:35 +0200

Page 1 of 5  [1] 2 3 4 5  Next page →

#83760 — "Performance of C++20's Ranges"

Three Benchmarks of C++20 Ranges vs Standard Algorithms

https://www.cppstories.com/2022/ranges-perf

--
Cholo Lennon
Bs.As.
ARG

[toc] | [next] | [standalone]

#83771

On Tue, 26 Apr 2022 01:13:41 -0300
Cholo Lennon <chololennon@hotmail.com> wrote:
>Three Benchmarks of C++20 Ranges vs Standard Algorithms
>
>https://www.cppstories.com/2022/ranges-perf

C++ used to be a svelt , clean language. Now its rapidly turning in Javas
brother with new huge APIs that no one asked for being added such as this.
If learning an API is more effort than writing code to do the same thing
yourself then the API should be binned.

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

#83773

Muttley@dastardlyhq.com wrote:
> C++ used to be a svelt , clean language. Now its rapidly turning in Javas
> brother with new huge APIs that no one asked for being added such as this.
> If learning an API is more effort than writing code to do the same thing
> yourself then the API should be binned.

The same story repeats again and again.

Back in the 90's the new C++ standard was criticized as being "too
complicated", "too inefficient", "too bloated", yada yada. After a time
most of these people stopped complaining.

Then C++11 came along, and people started complaining about how it's
"too complicated", "too bloated", contains too many features nobody
needs, yada yada, and how they would just stick to C++98 and not even
bother using C++11.

Then C++17 came along, and people said the exact same thing, but this
time they would stick to C++11 and forget about C++17.

Then C++20 came along, and once again people are telling the same thing.
Now C++17 is ok, but C++20 is too much.

You know, the same type of people who thought that C++11 was too much
and that they would stick to C++98.

Will this same thing repeat over and over with every major standard
revision?

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

#83789

On 4/26/2022 11:27 AM, Juha Nieminen wrote:
> Muttley@dastardlyhq.com wrote:
>> C++ used to be a svelt , clean language. Now its rapidly turning in Javas
>> brother with new huge APIs that no one asked for being added such as this.
>> If learning an API is more effort than writing code to do the same thing
>> yourself then the API should be binned.
> 
> The same story repeats again and again.

Not as far as I have seen.

> 
> Back in the 90's the new C++ standard was criticized as being "too
> complicated", "too inefficient", "too bloated", yada yada. After a time
> most of these people stopped complaining.

As far as I recall, at that time t standard was substantially the 
standardese version of Bjarne's book TC++PL (or, more precisely, 
Bjarne's book was the English version of the standard).
I have not heard such criticism, but I'd say it may have been more about 
complexity of the wording of the standard, rather than its contents.

> 
> Then C++11 came along, and people started complaining about how it's
> "too complicated", "too bloated", contains too many features nobody
> needs, yada yada, and how they would just stick to C++98 and not even
> bother using C++11.
> 

C++11 was a totally different story. C++ was a major change in the 
language (acknowledged by Bjarne himself as such), and it is 
understandable that with major change comes some skepticism.
However, as far as I can see most of the C++ development world has 
acknowledged that all in all C++11 was an improvement.

> Then C++17 came along, and people said the exact same thing, but this
> time they would stick to C++11 and forget about C++17.

C++17, on the other hand, is when criticism about excessive bloat of the 
language became dominant.

> 
> Then C++20 came along, and once again people are telling the same thing.
> Now C++17 is ok, but C++20 is too much.

As far as I can see C++20 has one good new feature, and that is concepts 
- except for the fact that the name "concepts" is straight wrong for the 
feature, it should have been type requirements, or template 
requirements; but let's not be too picky.

Most of the rest is unnecessary overhead, which deserves its critics.
After all, Bjarne himself has decided to take some distance from the 
committee, as of recent.

> 
> You know, the same type of people who thought that C++11 was too much
> and that they would stick to C++98.

I don't think it's the same kind of people.

Look, the 2005 draft of the standard from cppreference is 871 pages, the 
2011 draft is 1300 pages, and then growing and growing to a whopping 
1800+ pages for C++20.
That should say something.

> 
> Will this same thing repeat over and over with every major standard
> revision?

After C++17, that is likely to happen, unless the committee takes some 
serious change in direction.

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

#83914

On Tuesday, April 26, 2022 at 7:29:28 AM UTC-7, Manfred wrote:
> On 4/26/2022 11:27 AM, Juha Nieminen wrote: 
> > Mut...@dastardlyhq.com wrote: 
> >> C++ used to be a svelt , clean language. Now its rapidly turning in Javas 
> >> brother with new huge APIs that no one asked for being added such as this. 
> >> If learning an API is more effort than writing code to do the same thing 
> >> yourself then the API should be binned. 
> > 
> > The same story repeats again and again.
> Not as far as I have seen.
> > 
> > Back in the 90's the new C++ standard was criticized as being "too 
> > complicated", "too inefficient", "too bloated", yada yada. After a time 
> > most of these people stopped complaining.
> As far as I recall, at that time t standard was substantially the 
> standardese version of Bjarne's book TC++PL (or, more precisely, 
> Bjarne's book was the English version of the standard). 
> I have not heard such criticism, but I'd say it may have been more about 
> complexity of the wording of the standard, rather than its contents.
> > 
> > Then C++11 came along, and people started complaining about how it's 
> > "too complicated", "too bloated", contains too many features nobody 
> > needs, yada yada, and how they would just stick to C++98 and not even 
> > bother using C++11. 
> >
> C++11 was a totally different story. C++ was a major change in the 
> language (acknowledged by Bjarne himself as such), and it is 
> understandable that with major change comes some skepticism. 
> However, as far as I can see most of the C++ development world has 
> acknowledged that all in all C++11 was an improvement.
> > Then C++17 came along, and people said the exact same thing, but this 
> > time they would stick to C++11 and forget about C++17.
> C++17, on the other hand, is when criticism about excessive bloat of the 
> language became dominant.
> > 
> > Then C++20 came along, and once again people are telling the same thing. 
> > Now C++17 is ok, but C++20 is too much.
> As far as I can see C++20 has one good new feature, and that is concepts 
> - except for the fact that the name "concepts" is straight wrong for the 
> feature, it should have been type requirements, or template 
> requirements; but let's not be too picky. 
> 
> Most of the rest is unnecessary overhead, which deserves its critics. 
> After all, Bjarne himself has decided to take some distance from the 
> committee, as of recent.
> > 
> > You know, the same type of people who thought that C++11 was too much 
> > and that they would stick to C++98.
> I don't think it's the same kind of people. 
> 
> Look, the 2005 draft of the standard from cppreference is 871 pages, the 
> 2011 draft is 1300 pages, and then growing and growing to a whopping 
> 1800+ pages for C++20. 
> That should say something.
> > 
> > Will this same thing repeat over and over with every major standard 
> > revision?
> After C++17, that is likely to happen, unless the committee takes some 
> serious change in direction.

Is there a way to module the language features, I guess that is typetraits, 
I think typetraits in template, is for auto and ..., why ranges is any superscalar 
after iter:  I think iter is sequential.

Adding other features, besides, is for splitting "ranges" into "range features".

Ranges, gslices, ....

I think glices are guaranteed aligned.

Excuse me I only enjoy C++ and don't have to practice it.

For template though it comes up much easier than C and "m4".

There's h and hpp - I think declaration is still for the "forward" 
about typetraits after what for example results "ranges for ..., 
writter iter".

For "small containers with regular access", I don't know why 
ranges would be different access gslices, effective, "ranges".

This is where is where a "range" calculus, under relation, 
is any old indicator.

Maintaining summary statistics with result, basically is about 
"the summary statistics are seated with this sample or instead 
their own column array, access".  Then where it results "only as so 
much space as doubling the column stride", results in 
the "effectively single-iter access" or so.

Then where that's constant under terms, at least is eliminable.

So, "what is ranges" is "why is this not gslice".

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

#83774

On 26 Apr 2022 11:15, Muttley@dastardlyhq.com wrote:
> On Tue, 26 Apr 2022 01:13:41 -0300
> Cholo Lennon <chololennon@hotmail.com> wrote:
>> Three Benchmarks of C++20 Ranges vs Standard Algorithms
>>
>> https://www.cppstories.com/2022/ranges-perf
> 
> C++ used to be a svelt , clean language. Now its rapidly turning in Javas
> brother with new huge APIs that no one asked for being added such as this.
> If learning an API is more effort than writing code to do the same thing
> yourself then the API should be binned.

That's too weak a sentiment.

The Ranges library adds not just an new huge API but another large 
domain specific language which results in very brittle code, and huge 
complexity, that maintenance programmers must deal with.

Then there's the half baked continuations API, misleadingly called 
coroutines, which is the same except to top it off it's as mentioned 
half baked, just the half of what one needs to actually use.

And there's removal of earlier well defined features such as increasing 
addresses for struct members with same access, and code breaking changes 
such as of `std::filesystem::path::u8string` return type, where the 
updated code becomes both platform specific and inefficient.

So, C++20 is an unreliable, inefficient and needlessly complex version 
of the language, it's the Microsoft hipster idiot's version of C++, but 
from my few glimpses of features C++23 is even worse. :(


- Alf

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

#83779

Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote:
> The Ranges library adds not just an new huge API but another large 
> domain specific language which results in very brittle code, and huge 
> complexity, that maintenance programmers must deal with.

So if you want the same functionality in your program it's preferable
to implement it yourself, making it significantly less tested and thus
less reliable, and probably even more "brittle" (whatever that means)?
Also maintenance is probably going to only increase because your version
will inevitably be buggy or lacking.

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

#83780

On 26 Apr 2022 13:11, Juha Nieminen wrote:
> Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote:
>> The Ranges library adds not just an new huge API but another large
>> domain specific language which results in very brittle code, and huge
>> complexity, that maintenance programmers must deal with.
> 
> So if you want the same functionality in your program it's preferable
> to implement it yourself, making it significantly less tested and thus
> less reliable, and probably even more "brittle" (whatever that means)?
> Also maintenance is probably going to only increase because your version
> will inevitably be buggy or lacking.

Let's say that you don't want to deal with some APL code you found, but 
you want whatever effect it has, in C++.

Trying to implement APL yourself is an ungood way to go about it.

Implementation whatever that code does, in a natural way for C++, is a 
good way.

The result will not be as terse as the APL code, and it will not be as 
cryptic, if those qualities are important to you.

But, it will be generally faster and much more maintenable, and also 
faster to write except when the original author was an APL expert.


- Alf

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

#83784

On Tuesday, 26 April 2022 at 12:11:52 UTC+1, Juha Nieminen wrote:
> Alf P. Steinbach <alf.p.s...@gmail.com> wrote: 
> > The Ranges library adds not just an new huge API but another large 
> > domain specific language which results in very brittle code, and huge 
> > complexity, that maintenance programmers must deal with.
>
> So if you want the same functionality in your program it's preferable 
> to implement it yourself, making it significantly less tested and thus 
> less reliable, and probably even more "brittle" (whatever that means)? 
> Also maintenance is probably going to only increase because your version 
> will inevitably be buggy or lacking.
>
"Brittle" means that the code contains subtle interdependencies between
different parts, usually distant in "code space" (different modules, 
source files, called from different places in the program, a long way from
each other in a graph of class hierachies, etc), which means that modifications
can break the program in unexpected ways.
It's a criticism often levelled at object-oriented programming. 

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

#83802

On Tue, 26 Apr 2022 11:11:36 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote:
>> The Ranges library adds not just an new huge API but another large 
>> domain specific language which results in very brittle code, and huge 
>> complexity, that maintenance programmers must deal with.
>
>So if you want the same functionality in your program it's preferable
>to implement it yourself, making it significantly less tested and thus
>less reliable, and probably even more "brittle" (whatever that means)?
>Also maintenance is probably going to only increase because your version
>will inevitably be buggy or lacking.

You seem to assume everyone apart from the C++ committee is an idiot and
can't write basic algorithms correctly.

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

#83804

Muttley@dastardlyhq.com wrote:
> On Tue, 26 Apr 2022 11:11:36 -0000 (UTC)
> Juha Nieminen <nospam@thanks.invalid> wrote:
>>Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote:
>>> The Ranges library adds not just an new huge API but another large 
>>> domain specific language which results in very brittle code, and huge 
>>> complexity, that maintenance programmers must deal with.
>>
>>So if you want the same functionality in your program it's preferable
>>to implement it yourself, making it significantly less tested and thus
>>less reliable, and probably even more "brittle" (whatever that means)?
>>Also maintenance is probably going to only increase because your version
>>will inevitably be buggy or lacking.
> 
> You seem to assume everyone apart from the C++ committee is an idiot and
> can't write basic algorithms correctly.

No. Most experienced programmers are pretty intelligent and smart, and
most if not all of them make programming mistakes, even with the simplest
of algorithms or tasks. Why do you think that testing (eg. unit testing)
is such a huge deal in programming? Because programmers, no matter how
intelligent, how smart, how experienced, how talented, make mistakes,
even with the simplests of tasks.

One of the archetypal examples of this is implementing a binary search
of a sorted array. Give this task to programmers and quite a surprising
amount of them will implement it incorrectly (most typically making an
off-by-one error).

That's why, in general (unless there's a good reason not to), it's
better to use std::lower_bound or std::binary_search instead of writing
your own: The standard library implementation is pretty much guaranteed
to be bug-free.

Also, if you are reviewing code, maintaining code, writing unit tests for
some code, you can safely skip having to check if that std::lower_bound
actually works correctly. With a custom implementation you can't (and for
good reason).

And that's just with an algorithm as simple as a binary search. Consider
much more complex algorithms (or data containers).

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

#83810

On Wed, 27 Apr 2022 08:40:29 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>Muttley@dastardlyhq.com wrote:
>> On Tue, 26 Apr 2022 11:11:36 -0000 (UTC)
>> Juha Nieminen <nospam@thanks.invalid> wrote:
>>>Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote:
>>>> The Ranges library adds not just an new huge API but another large 
>>>> domain specific language which results in very brittle code, and huge 
>>>> complexity, that maintenance programmers must deal with.
>>>
>>>So if you want the same functionality in your program it's preferable
>>>to implement it yourself, making it significantly less tested and thus
>>>less reliable, and probably even more "brittle" (whatever that means)?
>>>Also maintenance is probably going to only increase because your version
>>>will inevitably be buggy or lacking.
>> 
>> You seem to assume everyone apart from the C++ committee is an idiot and
>> can't write basic algorithms correctly.
>
>No. Most experienced programmers are pretty intelligent and smart, and
>most if not all of them make programming mistakes, even with the simplest
>of algorithms or tasks. Why do you think that testing (eg. unit testing)
>is such a huge deal in programming? Because programmers, no matter how
>intelligent, how smart, how experienced, how talented, make mistakes,
>even with the simplests of tasks.

Depends how many times they've done it before. I've lost count of the times
I had to write a doubly linked list in C back in the day and I could almost do 
it with my eyes closed now.

>One of the archetypal examples of this is implementing a binary search
>of a sorted array. Give this task to programmers and quite a surprising
>amount of them will implement it incorrectly (most typically making an
>off-by-one error).
>
>That's why, in general (unless there's a good reason not to), it's
>better to use std::lower_bound or std::binary_search instead of writing
>your own: The standard library implementation is pretty much guaranteed
>to be bug-free.
>
>Also, if you are reviewing code, maintaining code, writing unit tests for
>some code, you can safely skip having to check if that std::lower_bound
>actually works correctly. With a custom implementation you can't (and for
>good reason).
>
>And that's just with an algorithm as simple as a binary search. Consider
>much more complex algorithms (or data containers).

Thats why I said basic algorithms. I'm not suggesting everyone should
re-implement red-black trees themselves.

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

#83814

Muttley@dastardlyhq.com writes:
>On Wed, 27 Apr 2022 08:40:29 -0000 (UTC)
>Juha Nieminen <nospam@thanks.invalid> wrote:

>>And that's just with an algorithm as simple as a binary search. Consider
>>much more complex algorithms (or data containers).
>
>Thats why I said basic algorithms. I'm not suggesting everyone should
>re-implement red-black trees themselves.

They probably should have done it once, during training on
data structures, along with building all the other standard
structures (stack, list, tree (binary, general, red/black, etc))
from first principles (including table-based implementations
where the links are indicies rather than pointers).

Best to undersatnd how it works along with strengths and
weaknesses  before using an algorithm, even canned versions.

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

#83815

On Wed, 27 Apr 2022 16:09:18 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Wed, 27 Apr 2022 08:40:29 -0000 (UTC)
>>Juha Nieminen <nospam@thanks.invalid> wrote:
>
>>>And that's just with an algorithm as simple as a binary search. Consider
>>>much more complex algorithms (or data containers).
>>
>>Thats why I said basic algorithms. I'm not suggesting everyone should
>>re-implement red-black trees themselves.
>
>They probably should have done it once, during training on
>data structures, along with building all the other standard
>structures (stack, list, tree (binary, general, red/black, etc))
>from first principles (including table-based implementations
>where the links are indicies rather than pointers).

In in interview once I was asked to write pseudo code for re-balancing a tree 
so it certainly does help!

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

#83888

Muttley@dastardlyhq.com writes:

> On Wed, 27 Apr 2022 16:09:18 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
>
>> Muttley@dastardlyhq.com writes:
>>
>>> On Wed, 27 Apr 2022 08:40:29 -0000 (UTC)
>>> Juha Nieminen <nospam@thanks.invalid> wrote:
>>>
>>>> And that's just with an algorithm as simple as a binary search.
>>>> Consider much more complex algorithms (or data containers).
>>>
>>> Thats why I said basic algorithms.  I'm not suggesting everyone
>>> should re-implement red-black trees themselves.
>>
>> They probably should have done it once, during training on
>> data structures, along with building all the other standard
>> structures (stack, list, tree (binary, general, red/black, etc))
>> from first principles (including table-based implementations
>> where the links are indicies rather than pointers).
>
> In in interview once I was asked to write pseudo code for
> re-balancing a tree so it certainly does help!

Just out of curiosity, what kind of tree were you asked to
rebalance?  Or did they not say what kind (in which case you
would get to pick)?

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

#83899

On Fri, 29 Apr 2022 16:15:10 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>Muttley@dastardlyhq.com writes:
>
>> On Wed, 27 Apr 2022 16:09:18 GMT
>> scott@slp53.sl.home (Scott Lurndal) wrote:
>>
>>> Muttley@dastardlyhq.com writes:
>>>
>>>> On Wed, 27 Apr 2022 08:40:29 -0000 (UTC)
>>>> Juha Nieminen <nospam@thanks.invalid> wrote:
>>>>
>>>>> And that's just with an algorithm as simple as a binary search.
>>>>> Consider much more complex algorithms (or data containers).
>>>>
>>>> Thats why I said basic algorithms.  I'm not suggesting everyone
>>>> should re-implement red-black trees themselves.
>>>
>>> They probably should have done it once, during training on
>>> data structures, along with building all the other standard
>>> structures (stack, list, tree (binary, general, red/black, etc))
>>> from first principles (including table-based implementations
>>> where the links are indicies rather than pointers).
>>
>> In in interview once I was asked to write pseudo code for
>> re-balancing a tree so it certainly does help!
>
>Just out of curiosity, what kind of tree were you asked to
>rebalance?  Or did they not say what kind (in which case you
>would get to pick)?

Just a standard binary tree IIRC but it was a long time ago and my memory
is hazy.

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

#83819

> One of the archetypal examples of this is implementing a binary search
> of a sorted array. Give this task to programmers and quite a surprising
> amount of them will implement it incorrectly (most typically making an
> off-by-one error).

That's my bounds.h:

#pragma once
#include <iterator>
#include <concepts>
#include <compare>
#include <cassert>
#include <iterator>
#include <algorithm>

template<std::random_access_iterator RandomIt, typename Key, typename Pred>
	requires requires( Pred pred, std::iter_value_t<RandomIt> &elem, Key 
const &key )
	{
		{ pred( elem, key ) } -> std::convertible_to<std::strong_ordering>;
	}
inline
constexpr RandomIt xlower_bound( RandomIt begin, RandomIt end, Key const 
&key, Pred pred )
{
	using namespace std;
	assert(end >= begin);
	size_t hit = end - begin, lower = 0, upper = hit, mid;
	while( lower != upper )
	{
		mid = lower + (upper - lower) / 2;
		if( pred( begin[mid], key ) >= 0 )
			hit = mid,
			upper = mid;
		else
			lower = mid + 1;
	}
	return begin + hit;
}

template<std::random_access_iterator RandomIt, typename Key, typename Pred>
	requires requires( Pred pred, std::iter_value_t<RandomIt> &elem, Key 
const &key )
	{
		{ pred( elem, key ) } -> std::convertible_to<std::strong_ordering>;
	}
inline
constexpr RandomIt xupper_bound( RandomIt begin, RandomIt end, Key const 
&key, Pred pred )
{
	using namespace std;
	assert(end >= begin);
	size_t hit = end - begin, lower = 0, upper = hit, mid;
	while( lower != upper )
	{
		mid = lower + (upper - lower) / 2;
		if( pred( begin[mid], key ) > 0 )
			hit = mid,
			upper = mid;
		else
			lower = mid + 1;
	}
	return begin + hit;
}

template<std::random_access_iterator RandomIt, typename Key, typename Pred>
	requires requires( Pred pred, std::iter_value_t<RandomIt> &elem, Key 
const &key )
	{
		{ pred( elem, key ) } -> std::convertible_to<std::strong_ordering>;
	}
constexpr std::pair<RandomIt, RandomIt> xequal_range( RandomIt begin, 
RandomIt end, Key const &key, Pred pred )
{
	using namespace std;
	assert(end >= begin);
	size_t hit = -1, lower = 0, upper = end - begin, mid;
	while( lower != upper )
	{
		mid = lower + (upper - lower) / 2;
		strong_ordering so = pred( begin[mid], key );
		if( so >= 0 )
		{
			if( so == 0 )
				hit = mid;
			upper = mid;
		}
		else
			lower = mid + 1;
	}
	if( hit == -1 )
		return pair<RandomIt, RandomIt>( end, end );
	begin += hit;
	hit = 0, lower = 1, upper = end - begin;
	while( lower != upper )
	{
		mid = lower + (upper - lower) / 2;
		strong_ordering so = pred( begin[mid], key );
		if( so > 0 )
			upper = mid;
		else
			assert(so == 0),
			hit = mid,
			lower = mid + 1;
	}
	end = begin + hit + 1;
	return pair<RandomIt, RandomIt>( begin, end );
}

template<std::random_access_iterator RandomIt, typename Key, typename Pred>
	requires requires( Pred pred, std::iter_value_t<RandomIt> &elem, Key 
const &key )
	{
		{ pred( elem, key ) } -> std::convertible_to<std::strong_ordering>;
	}
inline
constexpr RandomIt xbinary_search( RandomIt begin, RandomIt end, Key 
const &key, Pred pred )
{
	using namespace std;
	assert(end >= begin);
	size_t lower = 0, upper = end - begin, mid;
	while( lower != upper )
	{
		mid = lower + (upper - lower) / 2;
		strong_ordering so = pred( begin[mid], key );
		if( so == 0 )
			return begin + mid;
		if( so > 0 )
			upper = mid;
		else
			lower = mid + 1;
	}
	return end;
}


> That's why, in general (unless there's a good reason not to), it's
> better to use std::lower_bound or std::binary_search instead of writing
> your own: The standard library implementation is pretty much guaranteed
> to be bug-free.

The above implementations are a bit more convenient since they use
the three way comparison operator. And xbinary_search doesn't just
report if the array contains an element or not.

But interestingly for small arrays a simple linear search is faster
because of the inpredictible branches with the binary partitioning.

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

#83809

On 4/27/22 04:20, Muttley@dastardlyhq.com wrote:
> On Tue, 26 Apr 2022 11:11:36 -0000 (UTC)
> Juha Nieminen <nospam@thanks.invalid> wrote:
>> Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote:
>>> The Ranges library adds not just an new huge API but another large
>>> domain specific language which results in very brittle code, and
>>> huge complexity, that maintenance programmers must deal with.
>>
>> So if you want the same functionality in your program it's preferable
>> to implement it yourself, making it significantly less tested and thus
>> less reliable, and probably even more "brittle" (whatever that means)?
>> Also maintenance is probably going to only increase because your version
>> will inevitably be buggy or lacking.
>
> You seem to assume everyone apart from the C++ committee is an idiot and
> can't write basic algorithms correctly.

The committee isn't responsible for implementing the C++ standard
library. Oddly enough, that's the responsibility of the implementor.
While implementors can occasionally make idiotic mistakes, just like any
other programmer, their work (especially in the case of popular
implementations) gets a lot of real-life testing, and when it doesn't
work right, people complain back to the implementors. As a result,
popular C and C++ implementations have a definite tendency to be among
the most reliable software in the world. You should think twice about
wasting your time duplicating their efforts with code that will never be
anywhere near as heavily tested as theirs is.

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

#83826

James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> The committee isn't responsible for implementing the C++ standard
> library. Oddly enough, that's the responsibility of the implementor.
> While implementors can occasionally make idiotic mistakes, just like any
> other programmer, their work (especially in the case of popular
> implementations) gets a lot of real-life testing, and when it doesn't
> work right, people complain back to the implementors. As a result,
> popular C and C++ implementations have a definite tendency to be among
> the most reliable software in the world. You should think twice about
> wasting your time duplicating their efforts with code that will never be
> anywhere near as heavily tested as theirs is.

Although, to be fair, sometimes the standard can be slightly vague and
ambiguous, and different standard library implementors can have different
interpretations and thus different implementations.

Something like a year ago I made a bug report to the glibc developers.
As I read the C standard I think it's almost completely clear that the
swprintf() function should output an ending null character even if the
destination is too short to contain the entire would-be output (in the
exact same way as snprintf does. In other words swprintf() should behave
exactly like snprintf(), except that it deals with wide characters.)

For some reason the glibc developers have interpreted the C standard
in such a way that when it comes to swprintf(), it doesn't have to
output the ending null character if the destination is too short.
I don't see how this can be concluded from the C standard, so I sent
the bug report about a year ago.

It has had no reaction whatsoever from them.

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

#83801

Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote:
> The Ranges library adds not just an new huge API but another large 
> domain specific language which results in very brittle code, and huge 
> complexity, that maintenance programmers must deal with.

Ok, let me put it this way:

The ranges library is just that: A library. It's not part of the language
syntax itself. It's not making C++ "more complicated" because it's not
changing the C++ language itself. It's simply an ancillary auxiliary
library.

You treat these new standard libraries as if they made the language more
complicated and complex because from now forward you will have to encounter
C++ code that uses this library, meaning you will need to know what this
library is doing if you want to undrestand that code.

What you aren't considering is this: How is that different from programs
that use third-party libraries? There are very few C++ programs out there
that don't use *any* third-party libraries. A few programs may get away
with not using any (especially now that the standard library supports
more than it did before, eg. <filesystem> and <thread>), but those are
the minority. The larger the program, the more likely it's using some
third-party library.

That means that if you ever need to understand what the program is doing
(eg. to maintain it), you'll need to study how that third-party library
is used and how it works. (What's worse is that the "third-party library"
might be completely unique, ie. having been created by the author of the
program exclusively for that program, meaning there's zero chance you have
ever encountered it before.)

How is that different from having to find out how, for example, the
standard ranges library is used and how it works?

Well, I can tell you one big difference: Once you learn it you'll be able
to understand a whole lot of more C++ programs out there, if and ostensibly
when they start using it. With third-party libraries it's quite likely
you have never even heard of it, so every time you encounter one you'll
need to start learning from scratch.

Thus, there is quite a clear advantage in adding something to the standard
library: The more programs start using it, the less learning you'll have
to do in order to understand a C++ program.

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

Page 1 of 5  [1] 2 3 4 5  Next page →

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

csiph-web