www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Limitations of C++ range proposal

reply jmh530 <john.michael.hall gmail.com> writes:
I ran across this blog post on limitations of the C++ range 
proposal [1] and wrote up a simple D version in virtually no time.

https://run.dlang.io/is/y6uk18

import std.range : isInputRange, ElementType;

auto interspersed(T, U)(T x, U y)
     if (isInputRange!T && is(U : ElementType!T))
{
     import std.range : dropBackOne;
     import std.algorithm.iteration : map, joiner;

     return x.map!(a => [a, y]).joiner.dropBackOne;
}

void main()
{
     import std.range : iota;
     import std.array : array;

     auto x = iota(5);
     auto y = interspersed(x, 5);
     assert(y.array == [0, 5, 1, 5, 2, 5, 3, 5, 4, 5]);
}


[1] 
https://www.fluentcpp.com/2019/09/13/the-surprising-limitations-of-c-ranges-beyond-trivial-use-cases/
Sep 16 2019
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 09/16/2019 12:53 PM, jmh530 wrote:


 https://www.fluentcpp.com/2019/09/13/the-surprising-limitations-of-c-ra=


nges-beyond-trivial-use-cases/=20

=20


That article is about just one feature of C++ (ranges) and it exposes=20
many common issues with the language and its ecosystem. Four quotes from =

the article and my comments on each:

1) "having to come up with clever hacks to be able to do something as=20
basic as this is not a good sign"

Amen.

Personally, enable_if is the first thing that I've seen right away as a=20
hack.

2) "We need a reasonably coherent language that can be used by =E2=80=9Co=
rdinary=20
programmers=E2=80=9D whose main concern is to ship great applications on =
time.=20
[Bjarne Stroustrup]"

Amen.

3) "It=E2=80=99s as if the issues of limited usability, code complexity, =
leaky=20
abstractions and completely unreasonable compile-times are of no=20
consequence whatsoever to the committee members?"

Amen.

(Just today I've realized that C++ did not take boost::shared_array;=20
gotta research why that might have happened.)

4) "It seems to me that Bjarne Stroustrup=E2=80=99s plea from Remember th=
e Vasa!=20
fell on deaf ears (again, my subjective opinion)."

Amen!

Given all those important observations about C++ that are on just one=20
subject, C++ is proof how irrational humans can be. Humans continue=20
spending immeasurable amounts of time and money to stick with C++. We=20
should see anthropological, psychological, mass hysterical, whatever=20
research on this human behavior. (Stockholm syndrome has been suggested=20
in the past.)

Ali
Sep 16 2019
parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Monday, 16 September 2019 at 20:29:02 UTC, Ali Çehreli wrote:

 Given all those important observations about C++ that are on 
 just one subject, C++ is proof how irrational humans can be. 
 Humans continue spending immeasurable amounts of time and money 
 to stick with C++. We should see anthropological, 
 psychological, mass hysterical, whatever research on this human 
 behavior. (Stockholm syndrome has been suggested in the past.)


It's not too irrational to stick with a certain programming 
language. Is it more irrational for a team to
- continue building out an existing, working, potentially 
sprawling C++ code base or
- rewrite things in a different language entirely or
- introduce a second programming language for new features with 
corresponding interop challenges?

The reality is that there is a whole bunch of C++ code out there 
that you can't easily use from other programming languages. Some 
of the code is industry standard, a single implementation, and 
barely bindable to other compiled languages.* All this past 
investment in C++ codebases that is still paying off today  is 
what keeps people from moving on. In order to get people to 
switch away, you have to show them that they can get a larger 
payoff of some sorts by switching.

--

* A lot of published open source for professional graphics falls 
into that category.
Sep 17 2019
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 09/17/2019 04:39 AM, Gregor M=C3=BCckl wrote:

 On Monday, 16 September 2019 at 20:29:02 UTC, Ali =C3=87ehreli wrote:

 Given all those important observations about C++ that are on just one=





 subject, C++ is proof how irrational humans can be. Humans continue
 spending immeasurable amounts of time and money to stick with C++. We=





 should see anthropological, psychological, mass hysterical, whatever
 research on this human behavior. (Stockholm syndrome has been
 suggested in the past.)


 It's not too irrational to stick with a certain programming language.


Agreed because it's human to stick with status quo.


 Is
 it more irrational for a team to
 - continue building out an existing, working, potentially sprawling C+=


+

 code base or


Agreed again but most of those teams are hurting every single day on=20
every single line of code.


 - rewrite things in a different language entirely or
 - introduce a second programming language for new features with
 corresponding interop challenges?


Good points but I don't think good amount of thinking is applied to the=20
language choice. It's more like "No CTO will be fired for choosing C++."


 The reality is that there is a whole bunch of C++ code out there that
 you can't easily use from other programming languages. Some of the cod=


e

 is industry standard, a single implementation, and barely bindable to
 other compiled languages.* All this past investment in C++ codebases
 that is still paying off today  is what keeps people from moving on. I=


n

 order to get people to switch away, you have to show them that they ca=


n

 get a larger payoff of some sorts by switching.


I really don't think CTOs give serious thought on development costs=20
either. From my limited experience it was more like "we will go with C++"=
=2E


 * A lot of published open source for professional graphics falls into
 that category.


I don't have experience in that domain but I wrote ImageMagick bindings=20
once for an experimental project. (I used the C API; I don't know how=20
hard their C++ API would be to use with D.)

Recently I wrote a D API where alternative C++ API exists (for ROS).=20
Yes, I spent more time writing the API (three months total for the API=20
and the application itself) but in the end we gained expertise on the=20
domain, can make any change orimprovement whenever we want, and our code =

runs faster. Every situation will be different but I think we gained in=20
that case.

Ali
Sep 17 2019
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 09/16/2019 12:53 PM, jmh530 wrote:

 I ran across this blog post on limitations of the C++ range proposal [1]
 and wrote up a simple D version in virtually no time.


I had fun implementing the following version, which should not create 
any array:

import std.stdio;
import std.range;

auto interspersed(R, D)(R r, D delim) {
   struct MyRoundRobin {
     bool doDelim = false;

     auto empty() {
       return r.empty;
     }

     auto front() {
       return (doDelim ? delim : r.front);
     }

     auto popFront() {
       if (!doDelim) {
         r.popFront();
       }
       doDelim = !doDelim;
     }
   }

   return MyRoundRobin();
}

void main(){
   auto r = 10.iota.interspersed(42);
   writefln("%(%s %)", r);
}

std.range.roundRobin came close but it does not support 'StoppingPolicy' 
like 'zip' and 'lockstep' do.

Ali

P.S. I ran into a checked format string issue and created the following 
bug report:

  https://issues.dlang.org/show_bug.cgi?id=20218
Sep 16 2019
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/16/2019 2:47 PM, Ali Çehreli wrote:

 On 09/16/2019 12:53 PM, jmh530 wrote:
  > I ran across this blog post on limitations of the C++ range proposal [1]
  > and wrote up a simple D version in virtually no time.
 
 I had fun implementing the following version, which should not create any
array:


Please post D solutions to the reddit thread!!

https://www.reddit.com/r/programming/comments/d50n4j/the_surprising_limitations_of_c_ranges_beyond/
Sep 16 2019
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 16 September 2019 at 21:47:08 UTC, Ali Çehreli wrote:

 On 09/16/2019 12:53 PM, jmh530 wrote:

 I ran across this blog post on limitations of the C++ range


 proposal [1]

 and wrote up a simple D version in virtually no time.


 I had fun implementing the following version, which should not 
 create any array:
 [snip]



Even better!
Sep 16 2019
prev sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 09/16/2019 02:47 PM, Ali =C3=87ehreli wrote:


 auto interspersed(R, D)(R r, D delim) {
    struct MyRoundRobin {
      bool doDelim =3D false;

      auto empty() {
        return r.empty;
      }

      auto front() {
        return (doDelim ? delim : r.front);
      }

      auto popFront() {
        if (!doDelim) {
          r.popFront();
        }
        doDelim =3D !doDelim;
      }
    }

    return MyRoundRobin();
 }


That function causes an embarrassing closure allocation. Instead,

1) Both 'r' and 'delim' should be copied as members of the struct and
2) The struct should be defined as 'static'

I wrote something longer on the Learn forum:

   https://forum.dlang.org/thread/qm2cni$1ra7$1 digitalmars.com

Ali
Sep 20 2019