On 12/08/16 12:38, Guillaume Piolat wrote:
> From the best of my knowledge you cannot do these things in in C++:
>
> https://p0nce.github.io/d-idioms/#Precomputed-tables-at-compile-time-through-CTFE

I maintain an open source program called fakeroot-ng. It is written in C++. Just today, while doing some cleanups, I ran across this point when trying to convert a table to const.

So, yes, having a CTFE to compute the table would have been great, and had fakeroot-ng been written in D, I would have. Then again, the ultimate cost of not doing this is so low, that I didn't really feel cheated out of it.

That table was not expensive to compute, and its constantness wasn't crucial enough even for me to put a wrapper pointer and only access it through it. Had that not been the case, and had that table been more expensive to computer, I'd probably compute at compile time with an external tool.

The point is that while I missed have D's CTFE to compute that table, I didn't miss it much, and I don't miss D features often. Sadly, I cannot say the same thing about the things in C++ I miss when I write D. They are both everyday and, to me, without reasonable substitutes.

Shachar

On Friday, 12 August 2016 at 14:41:14 UTC, Shachar Shemesh wrote:
> I cannot say the same thing about the things in C++ I miss when I write D.

Be constructive and enumerate them.

On 11/08/16 18:41, Edward Diener wrote:
>
> 2) While I greatly respect the programming abilities of Mr. Bright and
> Mr. Alexandrescu and their hard work in creating and improving D, having
> followed both from the C++ world, the arrogance by which D was initially
> and repeatedly compared against C/C++ has been totally out of place
> since the beginning. C++ is a very good language and the effort made to
> denigrate it with specious and ridiculously false arguments about it
> vis-a-vis D as a programming language has almost irreparably hurt D as a
> serious programming language irrespective of its actual abilities or
> weaknesses. You are not going to appeal to the really intelligent
> programmers out there if you are not honest and rigorous in discussion
> of your own programming language in relation to others. All that you end
> up doing is to alienate anyone with real programming intelligence by the
> tactics that D has taken over the years with such comparisons.

To me, this is not so much the question of alienating C++ programmers, as it is that this arrogance is actively hindering D from becoming better. Any time I raise an issue I have with D, the discussion with both AA and WB seems more like an argument designed to prove to me that I am wrong than like a discussion aimed to make D better. Once they decide that something is best a certain way, it is very very difficult to make them see the downsides of that decision, much less act on it.

And, to me, this is an actual threat to D's future as a wide spread programming language. This attitude, if unchanged, will doom D to become a niche language, only suited for those who do not need it for anything that WB and AA have not thought of.

>
> 4) As a C++ programmer largely interested in C++ template programming,
> C++ concepts etc., and potential compile-time/run-time introspection, I
> have never found a compelling reason to use D rather than C++. I do
> recognize that C++'s template syntax is difficult and abstruse but I do
> not and have never seen where D improves upon these matters in any
> serious and rigorous way. This may be because the documentation about
> these areas in D is either very light or almost completely lacking. Even
> in Mr. Alexandrescu's book the discussion of these areas was very light
> in my estimation. So whatever D has to offer in these areas, if there
> are really impovements, is either lacking in the D documentation or does
> not really exist for me.

Here I'm not sure I follow you. I love C++, but its compile time execution is just horrible. Yes, if you are fluent with functional programming you will probably get by sufficiently, but since C++ isn't itself a functional language, this means doing C++ meta-programming requires a different programming paradigm than programming C++.

It is a very very very high barrier to pass.

Personally, I'm not a fan of doing too much during compile time. I think it introduces a level of complexity into your program, where the program as seen by the CPU is considerably different than the one you see in your source editor, that is hard to track and debug. As such, the weakness of C++'s meta programming has not been a major setback for me.

If you do like compile time programming, however, I don't see how you can claim that C++'s is good enough, when compared to D's.

Shachar

On Friday, 12 August 2016 at 12:27:50 UTC, Andrei Alexandrescu wrote:
>
> I recall I had a similar reaction as Edward back in the day. No hurt feelings or anything, but the arguments made were so specious I'd roll my eyes whenever I saw them in the C++ forums. -- Andrei

I already roll my eyes at these threads and I've only been using D for like a year or two. I'm amazed you still have eyes at this point.

On Friday, 12 August 2016 at 14:24:06 UTC, Steven Schveighoffer wrote:
> On 8/12/16 10:19 AM, bachmeier wrote:
>> On Friday, 12 August 2016 at 09:38:13 UTC, Guillaume Piolat wrote:
>>> From the best of my knowledge you cannot do these things in in C++:
>>
>> The most important thing is what you can't do in D: read a Scott Meyers
>> book.
>
> That's the last thing D needs.
>
> -Steve

Though people could enjoy an article explaining how shared works :)

On 8/12/16 11:28 AM, Kagamin wrote:
> Though people could enjoy an article explaining how shared works :)

First you have to find someone who knows how it works :)

All kidding aside, shared is pretty broken currently. If you want to know how it was *supposed* to work, you can read TDPL, though I'm not sure that's still valid.

-Steve

On Friday, 12 August 2016 at 14:41:14 UTC, Shachar Shemesh wrote:
> So, yes, having a CTFE to compute the table would have been great, and had fakeroot-ng been written in D, I would have. Then again, the ultimate cost of not doing this is so low, that I didn't really feel cheated out of it.

I was just giving examples of things that aren't possible in C++, or are possible but less easy, require external programs, require incredible macros...

If it's not easy it's as if it doesn't exist.

On Friday, 12 August 2016 at 14:41:14 UTC, Shachar Shemesh wrote:
>
> That table was not expensive to compute, and its constantness wasn't crucial enough even for me to put a wrapper pointer and only access it through it. Had that not been the case, and had that table been more expensive to computer, I'd probably compute at compile time with an external tool.
>
> Shachar

And you are forgetting about composability. If I can compute a table at compile-time this means I can go higher on the abstraction ladder.


void interpFast(string expr)(float x)
{
    // here a look-up computed at compile-time
    static immutable table = makeTable!exp(0, 100, 0.1f);
    int ipart = cast(int)x;
    int fpart = x - ipart;
    return linInterp(table[ipart], table[ipart+1], fpart);
}

void main()
{
   // automatically tabulated
   float x = interpFast!"pow(cos(x) + 4, x)"(0.5f);
}


Not only is this impossible in C++, but being cumbersome it means that people won't do it and loose optimization opportunities.

On Friday, 12 August 2016 at 12:27:50 UTC, Andrei Alexandrescu wrote:
> I recall I had a similar reaction as Edward back in the day. No hurt feelings or anything, but the arguments made were so specious I'd roll my eyes whenever I saw them in the C++ forums. -- Andrei

So what changed?  What gave you the initial kick to start moving from sideline scoffer to benevolent diarch?

-Wyatt

On Friday, 12 August 2016 at 15:43:54 UTC, Steven Schveighoffer wrote:
> All kidding aside, shared is pretty broken currently. If you want to know how it was *supposed* to work, you can read TDPL, though I'm not sure that's still valid.

Ah, was it Andrei, who tried to sell the idea that shared is a silver bullet for concurrency problems? That can explain why we have two different views on shared. Looks like a repetition of the story with autodecoding (with similar rationale).