www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The problem that took him 5 years to fix in C++, I solved in a minute

reply matheus <matheus gmail.com> writes:
Hi,

Today someone sent me this video: 
https://www.youtube.com/embed/ABg4_EV5L3w
(C++ Weekly - Ep 313 - The `constexpr` Problem That Took Me 5 
Years To Fix!).

It's a 26 minute long video of a guy trying to generate a 
concatenated string during CT in C++.

I was flabbergasted by the problems this poor guy had in front of 
him for a thing that shouldn't seem so complex (In my opinion of 
course). And more yet that he has being struggling with this for 
5 years.

So I decided to try the same with D, it was 14 lines[1] of code 
written in less than a minute and it just worked on the first 
try. Then I looked the Assembly code:

.L.str:
         .asciz  "hello world, hello world, hello world, "

After that I even asked over the D IRC channel if it was just 
this? And a user confirmed that my string was being generated 
through CT as the Assembly indicated.

Again incredible. My first programming language was C, then in 
2000-ish I had my first contact with C++ and I just hated and 
went back to C and then while looking for alternatives I stumbled 
on D which I use till this day as a "super C".

But now after so many years I couldn't believe the C++ is still 
struggling even to this day with this type of thing.

I'd like to quote this comment from the video:


 meowsqueak:
 "Well done solving this puzzle, but I’m left in shock. The need 
 to employ a template, static constexpr variables, a lambda 
 function, and four utility functions just to compile-time 
 generate a static string in C++ is an embarrassment."[2]


And indeed it is an embarrassment. Well D may have it flaws but I 
always found it lot time better or less restrictive language 
compared to others, especially C++.

Finally I'd like to take this moment and thank for all the effort.

Matheus.

[1] - Here is the snippet I wrote: https://godbolt.org/z/MsT36Prx4
[2] - Youtube comment: 
https://www.youtube.com/watch?v=ABg4_EV5L3w&lc=Ugzb7kTLS8GNS9bK07F4AaABAg

PS: I'm a ESL, sorry for any English mistakes.
Mar 09 2022
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
We can shorten that even further!

```d
import std.range : repeat, join;

pragma(msg, "hello world, ".repeat(3).join);
```
Mar 09 2022
prev sibling next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 3/9/22 9:01 PM, matheus wrote:

 Hi,
 
 Today someone sent me this video: https://www.youtube.com/embed/ABg4_EV5L3w
 (C++ Weekly - Ep 313 - The `constexpr` Problem That Took Me 5 Years To 
 Fix!).
 
 It's a 26 minute long video of a guy trying to generate a concatenated 
 string during CT in C++.
 
 I was flabbergasted by the problems this poor guy had in front of him 
 for a thing that shouldn't seem so complex (In my opinion of course). 
 And more yet that he has being struggling with this for 5 years.
 
 So I decided to try the same with D, it was 14 lines[1] of code written 
 in less than a minute and it just worked on the first try.


Watched a bunch of this video, and one thing that has stuck out to me -- 
the compiler is complaining about destructors.

One of the "side effects" of D having a builtin GC is that it perfectly 
fits the requirements of memory allocation at compile time as well. The 
heap is abstracted behind a different set of primitives, and apparently 
C++ cannot figure this out because they need to worry about 
destruction/free!

Am I reading this wrong?

-Steve
Mar 09 2022
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 10 March 2022 at 02:01:01 UTC, matheus wrote:

 Hi,

 Today someone sent me this video: 
 https://www.youtube.com/embed/ABg4_EV5L3w
 (C++ Weekly - Ep 313 - The `constexpr` Problem That Took Me 5 
 Years To Fix!).

 It's a 26 minute long video of a guy trying to generate a 
 concatenated string during CT in C++.

 I was flabbergasted by the problems this poor guy had in front 
 of him for a thing that shouldn't seem so complex (In my 
 opinion of course). And more yet that he has being struggling 
 with this for 5 years.

 So I decided to try the same with D, it was 14 lines[1] of code 
 written in less than a minute and it just worked on the first 
 try. Then I looked the Assembly code:

 .L.str:
         .asciz  "hello world, hello world, hello world, "

 After that I even asked over the D IRC channel if it was just 
 this? And a user confirmed that my string was being generated 
 through CT as the Assembly indicated.

 Again incredible. My first programming language was C, then in 
 2000-ish I had my first contact with C++ and I just hated and 
 went back to C and then while looking for alternatives I 
 stumbled on D which I use till this day as a "super C".

 But now after so many years I couldn't believe the C++ is still 
 struggling even to this day with this type of thing.

 I'd like to quote this comment from the video:


 meowsqueak:
 "Well done solving this puzzle, but I’m left in shock. The 
 need to employ a template, static constexpr variables, a 
 lambda function, and four utility functions just to 
 compile-time generate a static string in C++ is an 
 embarrassment."[2]


 And indeed it is an embarrassment. Well D may have it flaws but 
 I always found it lot time better or less restrictive language 
 compared to others, especially C++.

 Finally I'd like to take this moment and thank for all the 
 effort.

 Matheus.

 [1] - Here is the snippet I wrote: 
 https://godbolt.org/z/MsT36Prx4
 [2] - Youtube comment: 
 https://www.youtube.com/watch?v=ABg4_EV5L3w&lc=Ugzb7kTLS8GNS9bK07F4AaABAg

 PS: I'm a ESL, sorry for any English mistakes.


Well, a language alone doesn't make ecosystems, D is a good 
language, but after 10 years doesn't hold a candle to CUDA, 
Metal, Unreal, SYSCL, AUTOSAR/MISRA certifications, 
iOS/Android/Windows SDK, High Energy Physics research, 
PyTorch/Tensorflow, LLVM/GCC, ....

Before bashing C++'s design, which does indeed have plenty of 
flaws with several books describing them, what about finishing 
all those previews that are already 5 years and longer in the 
making and finally decide what domain D is good at?


where D was 10 years ago, Rust and Go have found out a way to 
push them into devs regardless of what they think about them, 
thanks all those Cloud Native Foundation projects, Khronos is 
slowly adopting Rust alongside C++ on some of their ongoing 
standard discussions.

Creating such ecosystems is what D should worry about, not how 
great a bare bones compiler is against the competition.
Mar 09 2022
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 10 March 2022 at 06:44:47 UTC, Paulo Pinto wrote:


 where D was 10 years ago, Rust and Go have found out a way to 
 push them into devs regardless of what they think about them, 
 thanks all those Cloud Native Foundation projects, Khronos is 
 slowly adopting Rust alongside C++ on some of their ongoing 
 standard discussions.


It was probably a good move for Rust and Go to go their own way, 
rather than copying others too much, in the sense that they stand 
out with one significant feature that is rare.


 Creating such ecosystems is what D should worry about, not how 
 great a bare bones compiler is against the competition.


D should start with fixing basic problems such as not being able 
to unify types with alias. C++ is currently ahead in 
meta-programming utility IMHO. Template composition is 
foundational for meta-programming, without proper aliases it is 
just not very practical.

After that the whole memory management and "shared" topic should 
be settled in a way that bring the language some unique 
advantages.

Until that is in place there is really no use in pointing to 
minor features like string concatenation, which basically has no 
measurable impact on true system level programming or advanced 
(non-macroish) meta programming for that matter.
Mar 10 2022
prev sibling next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 10 March 2022 at 06:44:47 UTC, Paulo Pinto wrote:

 Before bashing C++'s design, which does indeed have plenty of 
 flaws with several books describing them, what about finishing 
 all those previews that are already 5 years and longer in the 
 making and finally decide what domain D is good at?


Why? D being flawed does not take away one whit from C++'s 
issues. The C++ people are free to bash us right back. I don't 
follow this logic of "nobody is allowed to complain unless their 
own record is spotless." Nobody is ever spotless. Every language 
has warts. But of course you can complain about other languages' 
warts at any time you want! If I couldn't complain about the 
inadequacy of the tools that the profession considers adequate, I 
would certainly go crazy.
Mar 10 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 10 March 2022 at 11:32:07 UTC, FeepingCreature wrote:

 On Thursday, 10 March 2022 at 06:44:47 UTC, Paulo Pinto wrote:

 Before bashing C++'s design, which does indeed have plenty of 
 flaws with several books describing them, what about finishing 
 all those previews that are already 5 years and longer in the 
 making and finally decide what domain D is good at?


 Why?


Because negative advertising doesn't work, it is negative and 
will be perceived as whining.

Demonstrate what you are good at, but show your own merits.

Demonstrating feature parity with C++ would be good of course, so 
go for it when you are ready, but bragging about string 
concatenation won't win over any C++ programmer that needs what 
C++ is good for. It isn't something most C++ programmers care 
about.
Mar 10 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 10 March 2022 at 11:50:05 UTC, Ola Fosheim Grøstad 
wrote:

 Because negative advertising doesn't work, it is negative and 
 will be perceived as whining.


Advertising? This is a community forum, where community members 
express personal opinions. There's nothing wrong with discussions 
about the pros and cons of different programming languages as 
long as they're civil. I'm not about to tell people to never say 
anything negative about any language, including those same people 
who keep popping to remind us of D's shortcomings every time one 
of these discussions appears.

Yes, I understand that people new to D can see these forums, and 
that the tone of the posts here can influence their opinion of 
the language. That's one reason why the forums are moderated. But 
there's nothing wrong with the tone of this thread.

Discussions like this are perfectly fine, IMO. Every programming 
community I've ever been a part of has them. And I believe most 
people understand the difference between marketing and community 
discussion.
Mar 10 2022
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 10 March 2022 at 12:23:23 UTC, Mike Parker wrote:

 Discussions like this are perfectly fine, IMO. Every 
 programming community I've ever been a part of has them. And I 
 believe most people understand the difference between marketing 
 and community discussion.


You should of course not censor this, but complaining about other 
languages does not move the needle.

"show don't tell".
Mar 10 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 10 March 2022 at 13:30:35 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 10 March 2022 at 12:23:23 UTC, Mike Parker wrote:

 Discussions like this are perfectly fine, IMO. Every 
 programming community I've ever been a part of has them. And I 
 believe most people understand the difference between 
 marketing and community discussion.


 You should of course not censor this, but complaining about 
 other languages does not move the needle.

 "show don't tell".


So every discussion on this forum should be about improving D and 
nothing else? Come on. We have plenty of discussions about that.
Mar 10 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 10 March 2022 at 13:54:48 UTC, Mike Parker wrote:

 So every discussion on this forum should be about improving D 
 and nothing else? Come on. We have plenty of discussions about 
 that.


No, but there is way too much bashing of other languages, usually 
by people with a very limited knowledge of those languages and 
their primary usage scenarios. It looks bad and doesn't win 
anyone over.

Referencing other languages is only interesting if there is 
something you want to learn from them. There are thousands of 
languages with flaws, should we list them all? Makes no sense to 
me. Just makes the forums look juvenile.
Mar 10 2022
parent reply matheus <matheus gmail.com> writes:
On Thursday, 10 March 2022 at 14:34:44 UTC, Ola Fosheim Grøstad 
wrote:

 No, but there is way too much bashing of other languages, 
 usually by people with a very limited knowledge of those 
 languages and their primary usage scenarios. It looks bad and 
 doesn't win anyone over.


My main programming language is C and I admit that I have a 
limited knowledge in C++ and even in D (Remember I use D as super 
C), but I can see like many other comments on that same video, 
that the whole thing was overwhelmingly painful, Period.

Like I said above, that guy on the video is well known on C++ 
community and seeing him struggling with this feature made me 
wonder how a newcomer would feel?


 Referencing other languages is only interesting if there is 
 something you want to learn from them.


Oh, but there is something to learn here, that in this regard C++ 
is a lot painful compared to D.

By the way let just remember the title of the video: "The 
`constexpr` Problem That Took Me 5 Years To Fix!"

That must be a hint.

Matheus.
Mar 10 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 10 March 2022 at 14:50:31 UTC, matheus wrote:

 Like I said above, that guy on the video is well known on C++ 
 community and seeing him struggling with this feature made me 
 wonder how a newcomer would feel?


C++ is not friendly to beginners, and never will be. That is a 
well known fact.


 Referencing other languages is only interesting if there is 
 something you want to learn from them.


 Oh, but there is something to learn here, that in this regard 
 C++ is a lot painful compared to D.


Yes, D had the opportunity to learn from C++, yet there are more 
improvements useful for meta-programming in C++ release by 
release. So unless D starts to improve it is only a matter of 
time until that advantage is lost.


 By the way let just remember the title of the video: "The 
 `constexpr` Problem That Took Me 5 Years To Fix!"


constexpr is relatively new, not a done deal, and they improve on 
it iteratively based on usage experience. The usage setting is 
core to understanding language evolution. The evolution of C++ is 
very conservative and that is intentional.
Mar 10 2022
parent reply matheus <matheus gmail.com> writes:
On Thursday, 10 March 2022 at 15:10:42 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 10 March 2022 at 14:50:31 UTC, matheus wrote:

 Like I said above, that guy on the video is well known on C++ 
 community and seeing him struggling with this feature made me 
 wonder how a newcomer would feel?


 C++ is not friendly to beginners, and never will be. That is a 
 well known fact.


Neither for experienced users for what it seems, giving that the 
guy on the video has +10 years of experience in C++. :)

Matheus.
Mar 10 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 10 March 2022 at 16:29:38 UTC, matheus wrote:

 Neither for experienced users for what it seems, giving that 
 the guy on the video has +10 years of experience in C++. :)


Experienced in C++ after only 10 years? That makes him a 
genius!!! ;)
Mar 10 2022
prev sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 10 March 2022 at 12:23:23 UTC, Mike Parker wrote:

 On Thursday, 10 March 2022 at 11:50:05 UTC, Ola Fosheim Grøstad 
 wrote:

 Because negative advertising doesn't work, it is negative and 
 will be perceived as whining.


 Advertising? This is a community forum, where community members 
 express personal opinions. There's nothing wrong with 
 discussions about the pros and cons of different programming 
 languages as long as they're civil. I'm not about to tell 
 people to never say anything negative about any language, 
 including those same people who keep popping to remind us of 
 D's shortcomings every time one of these discussions appears.


It wouldn't be so bad if they were making good points. It's not 
productive to counter with "D isn't good at X" where X is neither 
on topic or relevant to the vast majority of programmers. It's an 
emotional response to someone pointing out weaknesses in C++. 
We'd all be better off if they'd stay in their C++ bubble and not 
vandalize otherwise interesting discussions.
Mar 10 2022
parent bachmeier <no spam.net> writes:
On Thursday, 10 March 2022 at 14:02:20 UTC, bachmeier wrote:

 On Thursday, 10 March 2022 at 12:23:23 UTC, Mike Parker wrote:

 On Thursday, 10 March 2022 at 11:50:05 UTC, Ola Fosheim 
 Grøstad wrote:

 Because negative advertising doesn't work, it is negative and 
 will be perceived as whining.


 Advertising? This is a community forum, where community 
 members express personal opinions. There's nothing wrong with 
 discussions about the pros and cons of different programming 
 languages as long as they're civil. I'm not about to tell 
 people to never say anything negative about any language, 
 including those same people who keep popping to remind us of 
 D's shortcomings every time one of these discussions appears.


 It wouldn't be so bad if they were making good points. It's not 
 productive to counter with "D isn't good at X" where X is 
 neither on topic or relevant to the vast majority of 
 programmers. It's an emotional response to someone pointing out 
 weaknesses in C++. We'd all be better off if they'd stay in 
 their C++ bubble and not vandalize otherwise interesting 
 discussions.


This is one of the most spectacular cases of off-topic 
vandalization of a forum discussion, in a thread announcing 
Facebook had started using D in production:

https://forum.dlang.org/post/wllaccthfrnvquuhsbsr forum.dlang.org
Mar 10 2022
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Thursday, 10 March 2022 at 06:44:47 UTC, Paulo Pinto wrote:


 where D was 10 years ago, Rust and Go have found out a way to 
 push them into devs regardless of what they think about them, 
 thanks all those Cloud Native Foundation projects, Khronos is 
 slowly adopting Rust alongside C++ on some of their ongoing 
 standard discussions.


Funny how a positive thread about D could become so negative 
quickly.



language in my opinion). C++20 might have better modelling power 
than D right now but I would say in practice D is still more 
powerful because the meta programming syntax is more accessible 
for the average programmer. Meta programming in C++ is still a 
kind of academic hair-splitting which also requires the 
programmer to spend a lot of time to learn and understand it. 
Obviously even experts have problems with it which this thread is 
about.

I think that one goal for D should be, can you write a function 
then you can do meta programming. If you think that D meta 
programming has flaws and can be improved, then it should be 
discussed in a new thread for each suggested improvement.
Mar 10 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 10 March 2022 at 15:02:43 UTC, IGotD- wrote:

 On Thursday, 10 March 2022 at 06:44:47 UTC, Paulo Pinto wrote:


 where D was 10 years ago, Rust and Go have found out a way to 
 push them into devs regardless of what they think about them, 
 thanks all those Cloud Native Foundation projects, Khronos is 
 slowly adopting Rust alongside C++ on some of their ongoing 
 standard discussions.


 Funny how a positive thread about D could become so negative 
 quickly.



 language in my opinion). C++20 might have better modelling 
 power than D right now but I would say in practice D is still 
 more powerful because the meta programming syntax is more 
 accessible for the average programmer. Meta programming in C++ 
 is still a kind of academic hair-splitting which also requires 
 the programmer to spend a lot of time to learn and understand 
 it. Obviously even experts have problems with it which this 
 thread is about.

 I think that one goal for D should be, can you write a function 
 then you can do meta programming. If you think that D meta 
 programming has flaws and can be improved, then it should be 
 discussed in a new thread for each suggested improvement.



compiler attributes, reflection and code generators.

Are they clunkier than D?


Orleans, CUDA (including GPGPU debugging), IoT (Meadows), Cloud 
SDKs for GCP/AWS/Azure, Blazor, Uno, MAUI,....

D, well it has MIR and vibe.d, that is about it.
Mar 10 2022
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 10 March 2022 at 15:49:36 UTC, Paulo Pinto wrote:


 compiler attributes, reflection and code generators.

 Are they clunkier than D?


 Orleans, CUDA (including GPGPU debugging), IoT (Meadows), Cloud 
 SDKs for GCP/AWS/Azure, Blazor, Uno, MAUI,....

 D, well it has MIR and vibe.d, that is about it.


I feel compelled to mention dcompute here as a competitor for 
CUDA. It is a substitute for the kernel language and the runtime 
is just as easy to use. It can run on CUDA ( as a backend) so all 
the same tools will work including debugging (modulo probably 
demangling support).
Mar 10 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 11 March 2022 at 04:03:50 UTC, Nicholas Wilson wrote:

 On Thursday, 10 March 2022 at 15:49:36 UTC, Paulo Pinto wrote:


 compiler attributes, reflection and code generators.

 Are they clunkier than D?


 Remedy?), Orleans, CUDA (including GPGPU debugging), IoT 
 (Meadows), Cloud SDKs for GCP/AWS/Azure, Blazor, Uno, MAUI,....

 D, well it has MIR and vibe.d, that is about it.


 I feel compelled to mention dcompute here as a competitor for 
 CUDA. It is a substitute for the kernel language and the 
 runtime is just as easy to use. It can run on CUDA ( as a 
 backend) so all the same tools will work including debugging 
 (modulo probably demangling support).


What is dcompute answer to Hybridizer alongsiside Visual Studio 
and Nsights?

https://developer.nvidia.com/blog/hybridizer-csharp/

https://developer.nvidia.com/nsight-visual-studio-edition
Mar 10 2022
next sibling parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Friday, 11 March 2022 at 06:41:37 UTC, Paulo Pinto wrote:

 On Friday, 11 March 2022 at 04:03:50 UTC, Nicholas Wilson wrote:

 On Thursday, 10 March 2022 at 15:49:36 UTC, Paulo Pinto wrote:


 compiler attributes, reflection and code generators.

 Are they clunkier than D?


 Remedy?), Orleans, CUDA (including GPGPU debugging), IoT 
 (Meadows), Cloud SDKs for GCP/AWS/Azure, Blazor, Uno, 
 MAUI,....

 D, well it has MIR and vibe.d, that is about it.


 I feel compelled to mention dcompute here as a competitor for 
 CUDA. It is a substitute for the kernel language and the 
 runtime is just as easy to use. It can run on CUDA ( as a 
 backend) so all the same tools will work including debugging 
 (modulo probably demangling support).


 What is dcompute answer to Hybridizer alongsiside Visual Studio 
 and Nsights?

 https://developer.nvidia.com/blog/hybridizer-csharp/

 https://developer.nvidia.com/nsight-visual-studio-edition


I enjoyed the pretty graphs and summaries produced by Nsight back 
in my CUDA days but I was then, and still am, more interested in 
the leverage provided by language directly.

That said, we can add tooling, and we should.  For all I know 
hooking dcompute code into Nsight, for example, may be as easy as 
running under a C++ main and linking with nvcc.  I plan to pitch 
in on dcompute myself after the current project and enabling 
Nsight seems like a good place to start (maybe someone has 
already done it, I've not looked for it...)

dcompute can be improved but in my experience it is, already, 
head and shoulders above C++ when it comes to producing readable, 
performant, kernels quickly.  OTOH, if you're a total tool fanboy 
you're probably better off with something else, at least for now.

I've not tried Csharp on GPUs, hybridizer or otherwise.  Was the 
GPU meta programming capability there not too "clunky"?  How did 
your performance compare to well crafted C++/CUDA implementations?
Mar 11 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 11 March 2022 at 09:37:41 UTC, Bruce Carneal wrote:

 On Friday, 11 March 2022 at 06:41:37 UTC, Paulo Pinto wrote:

 On Friday, 11 March 2022 at 04:03:50 UTC, Nicholas Wilson 
 wrote:

 On Thursday, 10 March 2022 at 15:49:36 UTC, Paulo Pinto wrote:


 compiler attributes, reflection and code generators.

 Are they clunkier than D?


 Remedy?), Orleans, CUDA (including GPGPU debugging), IoT 
 (Meadows), Cloud SDKs for GCP/AWS/Azure, Blazor, Uno, 
 MAUI,....

 D, well it has MIR and vibe.d, that is about it.


 I feel compelled to mention dcompute here as a competitor for 
 CUDA. It is a substitute for the kernel language and the 
 runtime is just as easy to use. It can run on CUDA ( as a 
 backend) so all the same tools will work including debugging 
 (modulo probably demangling support).


 What is dcompute answer to Hybridizer alongsiside Visual 
 Studio and Nsights?

 https://developer.nvidia.com/blog/hybridizer-csharp/

 https://developer.nvidia.com/nsight-visual-studio-edition


 I enjoyed the pretty graphs and summaries produced by Nsight 
 back in my CUDA days but I was then, and still am, more 
 interested in the leverage provided by language directly.

 That said, we can add tooling, and we should.  For all I know 
 hooking dcompute code into Nsight, for example, may be as easy 
 as running under a C++ main and linking with nvcc.  I plan to 
 pitch in on dcompute myself after the current project and 
 enabling Nsight seems like a good place to start (maybe someone 
 has already done it, I've not looked for it...)

 dcompute can be improved but in my experience it is, already, 
 head and shoulders above C++ when it comes to producing 
 readable, performant, kernels quickly.  OTOH, if you're a total 
 tool fanboy you're probably better off with something else, at 
 least for now.

 I've not tried Csharp on GPUs, hybridizer or otherwise.  Was 
 the GPU meta programming capability there not too "clunky"?  
 How did your performance compare to well crafted C++/CUDA 
 implementations?


I guess it is good enough to keep their business going, 
http://www.altimesh.com/
Mar 13 2022
parent Bruce Carneal <bcarneal gmail.com> writes:
On Monday, 14 March 2022 at 00:42:34 UTC, Paulo Pinto wrote:

 On Friday, 11 March 2022 at 09:37:41 UTC, Bruce Carneal wrote:

 On Friday, 11 March 2022 at 06:41:37 UTC, Paulo Pinto wrote:




...

 I've not tried Csharp on GPUs, hybridizer or otherwise.  Was 
 the GPU meta programming capability there not too "clunky"?  
 How did your performance compare to well crafted C++/CUDA 
 implementations?


 I guess it is good enough to keep their business going, 
 http://www.altimesh.com/


Indeed.  Business success with a language pretty much closes out 
the "is the language good enough" argument (for successful dlang 
companies as well of course).

Still, I thought we were addressing comparative benefit rather 
than "good enough".

Concretely, I prefer dcompute to my former GPU development 
language, C++/CUDA: quicker development, more readable, easier to 
make non-trivial kernels "live in registers", better launch API, 
...



opinions about dlang/dcompute, good or bad, please ask them to 
comment.
Mar 13 2022
prev sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 11 March 2022 at 06:41:37 UTC, Paulo Pinto wrote:

 What is dcompute answer to Hybridizer alongsiside Visual Studio 
 and Nsights?

 https://developer.nvidia.com/blog/hybridizer-csharp/

 https://developer.nvidia.com/nsight-visual-studio-edition


Hybridizer, seems to be the MSIL equivalent of dcompute.

As for VS, there is VisualD, and failing that you can get a lot 
of milage from pretending to be C++ and using the regular 
debugging tools for CUDA when you use the CUDA backend of 
dcompute.

I've not used NSight, but I don't see why it couldn't be used 
with VisualD.
Mar 11 2022
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 10 March 2022 at 15:49:36 UTC, Paulo Pinto wrote:

 D, well it has MIR and vibe.d, that is about it.


Dplug is an audio plugin framework with support for 
Linux/macOS/Windows, VST2/VST3/AAX/LV2/AUv2, with unique features 
being the following: PBR rendering, UI scripting, manages 
installers and notarization, ARM compatibility layer at the 
intrinsics level etc...
making it interesting agains frameworks with a 15 years headstart.

It certainly helps to write it in D, and it helps its users too, 
who actually prefers it over the (C++) incumbent. Go figure.
Mar 14 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 14 March 2022 at 09:51:34 UTC, Guillaume Piolat wrote:

 On Thursday, 10 March 2022 at 15:49:36 UTC, Paulo Pinto wrote:

 D, well it has MIR and vibe.d, that is about it.


 Dplug is an audio plugin framework with support for 
 Linux/macOS/Windows, VST2/VST3/AAX/LV2/AUv2, with unique 
 features being the following: PBR rendering, UI scripting,


Interesting that you have added PBR, is this real time or for 
rendering of static images?
Mar 20 2022
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 20 March 2022 at 10:52:31 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 14 March 2022 at 09:51:34 UTC, Guillaume Piolat 
 wrote:

 On Thursday, 10 March 2022 at 15:49:36 UTC, Paulo Pinto wrote:

 D, well it has MIR and vibe.d, that is about it.


 Dplug is an audio plugin framework with support for 
 Linux/macOS/Windows, VST2/VST3/AAX/LV2/AUv2, with unique 
 features being the following: PBR rendering, UI scripting,


 Interesting that you have added PBR, is this real time or for 
 rendering of static images?


It is optimized (all vector, parallelized tiled, dirty 
rectangles, mipmapped) but ultimately if you really want 60fps 
it's better to use the "raw" layer on top to redraw.
(typically: the background of a widget is in the PBR layer, and 
the curve and points on top are in the Raw layer and real-time 
updated. This caches the PBR layer output.).
Saving CPU is always useful for general audio stability, so GUI 
bottlenecks are quite important.

All in all: more GUI work, less filesize, larger memory usage 
(about 60mb more per instance), a look that can look 
approximately realistic, and when doing the UI it can feel like 
sculpting.
Mar 20 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 20 March 2022 at 11:06:05 UTC, Guillaume Piolat wrote:

 It is optimized (all vector, parallelized tiled, dirty 
 rectangles, mipmapped) but ultimately if you really want 60fps 
 it's better to use the "raw" layer on top to redraw.
 (typically: the background of a widget is in the PBR layer, and 
 the curve and points on top are in the Raw layer and real-time 
 updated. This caches the PBR layer output.).
 Saving CPU is always useful for general audio stability, so GUI 
 bottlenecks are quite important.


Sounds nice, so it is all CPU and no GPU if I didn't misinterpret 
what you wrote. Do you know if any other audio-plugins do this as 
well? I always assumed they used pre-rendered images for fancy 
widgets like knobs and sliders.


 All in all: more GUI work, less filesize, larger memory usage 
 (about 60mb more per instance), a look that can look 
 approximately realistic, and when doing the UI it can feel like 
 sculpting.


Maybe this can be turned into a generic UI library for D? Or is 
it more geared towards smaller user-interfaces like those 
commonly found in audio-plugins?
Mar 20 2022
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 20 March 2022 at 20:00:22 UTC, Ola Fosheim Grøstad 
wrote:

 Sounds nice, so it is all CPU and no GPU if I didn't 
 misinterpret what you wrote.


Yes. Using the GPU is not that much of a win since for text and 
curve you'd end up sending to the driver large amounts of 
vertices, and the compability headache that the GPU cause are 
endless. OpenGL is deprecated on macOS, so you need a layer on 
top, so you need a shader language... it quickly gets hairy.



 I always assumed they used pre-rendered images for fancy 
 widgets like knobs and sliders.


A lot of them do, the equivalent with PBR is have one image and 
rotate this, and recompute  shadows and reflections from there ; 
it drastically lowers memory requirements and image decoding time.



 Maybe this can be turned into a generic UI library for D? Or is 
 it more geared towards smaller user-interfaces like those 
 commonly found in audio-plugins?


It is very specialized and unsuitable for generic UI, where you 
don't have a reference to thr UX of hardware racks.
Mar 20 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 20 March 2022 at 20:27:44 UTC, Guillaume Piolat wrote:

 It is very specialized and unsuitable for generic UI, where you 
 don't have a reference to thr UX of hardware racks.


Btw, I haven't tried this, but there appears to be 
(experimental?) [DPlug support in 
Faust](https://github.com/grame-cncm/faust/blob/master-dev/architecture/dplug.d).

The C++ codegen generates UI-hooks, so I assume the D version 
does too?
Apr 22 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 22 April 2022 at 15:23:46 UTC, Ola Fosheim Grøstad 
wrote:

 The C++ codegen generates UI-hooks, so I assume the D version 
 does too?


I tested. The dlang output is almost the same as the C++ output.
Apr 22 2022
prev sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 10 March 2022 at 06:44:47 UTC, Paulo Pinto wrote:

 Creating such ecosystems is what D should worry about, not how 
 great a bare bones compiler is against the competition.


+1
The win condition is when one sort of software X is faster to 
build with D than with any other known method.
Mar 10 2022
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
This would make a great post on HackerNews or Reddit! Please do so.

P.S. I sent you email about this, but your email address doesn't work.
Mar 10 2022
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 10 March 2022 at 02:01:01 UTC, matheus wrote:

 Hi,


I hope to see the official priority list of D.
Mar 10 2022
next sibling parent zjh <fqbqrr 163.com> writes:
Hope to see D's `vision(or position), roadmap and continue 
changing progress bar` on the home page from time to time.
D should have a dynamic priority list of `features/todo`. and 
letting users known. and it should put on the `dlang homepage`.
Then new and old users can `intuitively` feel the progress . 
Otherwise,plain users don't know the `power` of d.
Just like `C++` now has no `user defined attributes`, which is 
very uncomfortable.
We should show `our strengths` on the home page.
In addition, we should `dig into` the good posts of skilled users 
of `d Forum` and classify them and, reward them for their 
`excellent answers`. Then, we can avoid answering the same 
questions repeatedly by just providing a link.
Mar 10 2022
prev sibling parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 10 March 2022 at 11:11:31 UTC, zjh wrote:


 I hope to see the official priority list of D.


  We should brainstorm which `features` and which `key defects` is 
important,and determine the `priority items` in combination with 
`complexity/time consumption/cost-benefit ratio`.
Mar 10 2022
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 10 March 2022 at 11:52:02 UTC, zjh wrote:

 On Thursday, 10 March 2022 at 11:11:31 UTC, zjh wrote:


 I hope to see the official priority list of D.


  We should brainstorm which `features` and which `key defects` 
 is important,and determine the `priority items` in combination 
 with `complexity/time consumption/cost-benefit ratio`.


According to Mike Parker's latest D Foundation update [1], this 
was discussed in the "Vision Meeting" in February, and the plan 
is to produce a written document in time for this year's DConf.

[1] 
https://forum.dlang.org/post/qrtjqubrbuqeiffunili forum.dlang.org
Mar 10 2022
parent zjh <fqbqrr 163.com> writes:
On Thursday, 10 March 2022 at 11:55:58 UTC, Paul Backus wrote:
https://forum.dlang.org/post/qrtjqubrbuqeiffunili forum.dlang.org


This link should be provided on the `dlang home page` and there 
should be a `progress bar` for how much is done.
Like `std.v3`, no one knows the progress.
As users, we should know the progress of major developers of d 
transparently.
We need to know the `comparison` with other languages and the 
`real situation`.
I translated many `d forum posts`,and I also want `dlang home 
page` to have a link to my website.
In this way, D Chinese users can access and learn d from it 
directly.
Mar 10 2022
prev sibling next sibling parent zjh <fqbqrr 163.com> writes:
On Thursday, 10 March 2022 at 11:52:02 UTC, zjh wrote:


 I hope to see the official priority list of D.




We need a `real` comparison between D and other main languages.
After you get the comparison out, let the user choose by himself.
We should strengthen the D language's `pros` like 
`metaprogramming` and make up for `important defects`.
Mar 10 2022
prev sibling parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 10 March 2022 at 11:52:02 UTC, zjh wrote:


 I hope to see the official priority list of D.





D language has another `advantage` and should be `displayed` on 
the home page:
That is,`d` is very good for small `entrepreneurs and businesses`.
Because d itself is a `small team `. There is no such thing as 
"shop bullying".
I think d can be positioned to serve `excellent 
programmers/entrepreneurs`.
Focusing on "excellent" programmers is a good positioning.
[here is a chinese article on the advantages of `d` written by 
Russians, and the original site is 
disappeared](https://fqbqrr.blog.csdn.net/article/details/109110021)
We should let the advantages of d known to all programmers.
Mar 10 2022
parent reply Basile B. <b2.temp gmx.com> writes:
On Thursday, 10 March 2022 at 12:43:12 UTC, zjh wrote:

 On Thursday, 10 March 2022 at 11:52:02 UTC, zjh wrote:


 I hope to see the official priority list of D.





 D language has another `advantage` and should be `displayed` on 
 the home page:
 That is,`d` is very good for small `entrepreneurs and 
 businesses`.
 [...]


`is` it `how` you would `describe` yourself ?
Mar 10 2022
parent zjh <fqbqrr 163.com> writes:
On Thursday, 10 March 2022 at 13:33:09 UTC, Basile B. wrote:


 `is` it `how` you would `describe` yourself ?


I am a learner.

D is a `minority` language. Only those who dare to try it will 
get its benefits.
D should try to satisfy `excellent` programmers.
Make `excellent` programmers comfortable and let them show off 
the D language.
Mar 10 2022
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 10 March 2022 at 02:01:01 UTC, matheus wrote:

 Hi,

 Today someone sent me this video: 
 https://www.youtube.com/embed/ABg4_EV5L3w
 (C++ Weekly - Ep 313 - The `constexpr` Problem That Took Me 5 
 Years To Fix!).

 It's a 26 minute long video of a guy trying to generate a 
 concatenated string during CT in C++.

 I was flabbergasted by the problems this poor guy had in front 
 of him for a thing that shouldn't seem so complex (In my 
 opinion of course). And more yet that he has being struggling 
 with this for 5 years.


Reminds me of this CppCon talk by Andrei Alexandrescu that was 
posted in the community Discord recently:

https://youtu.be/va9I2qivBOA

Once you get through all of the background material in the first 
half, the payoff is...a bunch of clever workarounds for the fact 
that C++ doesn't have static foreach.

Of course, Andrei knows this--one of his early slides even says, 
"static for needed for simple implementation". But evidently the 
C++ committee has not yet been convinced.
Mar 10 2022
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10.03.22 12:52, Paul Backus wrote:

 
 Reminds me of this CppCon talk by Andrei Alexandrescu that was posted in 
 the community Discord recently:
 
 https://youtu.be/va9I2qivBOA


Nice talk, but the explanation why there is a quadratic number of 
template instantiations for `destroyLog` seems to be wrong.

`destroyLog` itself is actually only instantiated a linear number of 
times. In particular, it is not true that it is instantiated with every 
combination of `lo` and `hi` where `0≤lo<hi≤n`. Most of them are never 
reached.

E.g., n=8, recursion tree of (lo,hi)-arguments:

```
                      (0,8)
                /               \
          (0,4)                   (4,8)
         /     \                 /     \
    (0,2)       (2,4)       (4,6)       (6,8)
    /   \       /   \       /   \       /   \
(0,1) (1,2) (2,3) (3,4) (4,5) (5,6) (6,7) (7,8)
```

Of course, the number of instantiated templates is indeed quadratic 
because each static index operation instantiates a linear number of 
templates and there are n index operations.

There is also something weird going on with the computation of the 
middle point:

```c++
constexpr size_t m = lo + (hi + low)/2;
```

This should be

```c++
constexpr unsigned m = lo + (hi - lo)/2;
```

(Or just (lo + hi)/2, I highly doubt this is ever going to wrap around 
:o). )

The following glorious hack avoids the linear indexing by consuming each 
element in the type sequence exactly once, when it is needed. The 
template parameter Ts is a type_sequence and the automatically deducted 
function return type is Ts[hi - lo .. $].

This only causes a linear number of template instantiations.

```c++
template<unsigned lo,unsigned hi,typename Ts>
auto destroyLog(unsigned i,void *p){
     static_assert(lo < hi);
     assert(lo <= i && i < hi);
     if constexpr (lo + 1 != hi) {
         constexpr unsigned m = lo + (hi - lo)/2;
         using Rs = decltype(destroyLog<lo, m, Ts>(i, p));
         if (i < m){
             destroyLog<lo, m, Ts>(i, p);
             return decltype(destroyLog<m, hi, Rs>(i, p))();
         } else {
             return destroyLog<m, hi, Rs>(i, p);
         }
     } else{
         using T = typename head<Ts>::type;
         static_cast<T*>(p)->~T();
         return typename tail<Ts>::type();
     }
}
```
Mar 10 2022
prev sibling next sibling parent reply matheus <matheus gmail.com> writes:
Hi again,

Well I'll reply myself instead of making individual responses to 
not pollute this topic too much, but overall I see some people 
complaining that I was bashing C++, and all can I say it was NOT 
on purpose.

I was just pointing out one case that was in fact very 
embarrassing in my opinion.

This video is from Jason and he is well known on the C++ 
community and even gave some presentations on CppCon, so it was 
amusing seeing him struggling with the language for something 
that I could do easily in D (Again I'm not a D hardcore at all).

I think that differently from some people here I like D's GC, I 
never had much problem with it (Knocking on the wood), and even 
that I don't use much templates I prefer the D way in contrast 
with C++ and I could go on with this, but I think you get the 
gist.

I usually watch videos from CppCon from time to time to see 
what's new, and to be honest most of the new features presented 
there for me seems to be clumsy or overwhelmingly painful to work 
with and not so simple compared with D.

On Thursday, 10 March 2022 at 08:30:06 UTC, Walter Bright wrote:

 ...
 P.S. I sent you email about this, but your email address 
 doesn't work.


First sorry for that, but this is true and the reason is just to 
avoid spam, I post from the forum.dlang.org and while I don't 
know if this still the case, but there was a time in the past 
where the e-mail address was being leaked and could be found 
through google, so I use a random one just to post.

Matheus.

PS: I'm a ESL, sorry for any English mistake.
Mar 10 2022
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 3/10/22 06:35, matheus wrote:


 This video is from Jason and he is well known on the C++ community and
 even gave some presentations on CppCon, so it was amusing seeing him
 struggling with the language for something that I could do easily in D
 (Again I'm not a D hardcore at all).


I appreciate this thread.

I am sorry C++ has so many bright people like Jason Turner in its grasp. 
Jason Turner has been evangelizing "constexpr everything", not realizing 
that would make the keyword effectively a whitespace word, which would 
mean the need for the constexpr keyword is dubious. (Hint: D does not 
have such a keyword.) Despite appearances, C++ is a net loss to 
humanity. All those bright people could be spending their time actually 
solving engineering problems instead of finding brilliant workarounds to 
C++'s deficiencies.

To respond to another point in this thread, I am not embarrassed to 
admit that I am emotional. I actually like to be emotional. Thank you 
very much! :)

Besides, occasional C++ people who read these threads should be told the 
truth.


 I like D's GC, I never had much problem with it (Knocking on the wood)


I regret even attempting to defend D's GC to enlightened (!) C++ people. 
I used to be one myself. Now I simply solve problems with D and have fun 
doing it. The GC just works. How about redirecting some of the energy 
people put into C++ to learning different memory management strategies...


 I usually watch videos from CppCon from time to time to see what's new,
 and to be honest most of the new features presented there for me seems
 to be clumsy or overwhelmingly painful to work with and not so simple
 compared with D.


Again, I am sorry that so many bright people think they are stuck with 
C++ and have to keep learning convoluted workarounds, some of which are 
ISO standard additions to the language.


 PS: I'm a ESL


Me too.


 sorry for any English mistake.


You are doing everyone a favor by writing in English. Thank you! :)

Ali
Mar 10 2022
next sibling parent David Gileadi <gileadisNOSPM gmail.com> writes:
On 3/10/22 11:47 AM, Ali Çehreli wrote:

 On 3/10/22 06:35, matheus wrote:
  > sorry for any English mistake.
 
 You are doing everyone a favor by writing in English. Thank you! :)


And you write it quite well, I might add. Thanks for the post!
Mar 10 2022
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 10, 2022 at 10:47:51AM -0800, Ali Çehreli via Digitalmars-d wrote:

 On 3/10/22 06:35, matheus wrote:
 

 This video is from Jason and he is well known on the C++ community
 and even gave some presentations on CppCon, so it was amusing seeing
 him struggling with the language for something that I could do
 easily in D (Again I'm not a D hardcore at all).




I used C++ extensively for many years before I switched to D.  I can say
from experience that metaprogramming takes off to a whole new level when
no special syntax is needed to do it. I.e., compile-time code is written
basically in the same way as runtime code (CTFE), no need to switch to
some DSL or sub-language dedicated for metaprogramming.  Instead of
convoluted shenanigans to navigate C++'s fractal minefield of misfit
quirks, you just write straight D code like you would any normal runtime
code, and it can be executed by CTFE without further ado. This is an
extremely powerful correspondence that makes metaprogramming as easy as
normal code, not some arcane black magic that only the initiated can
ever hope to approach.

You can see the same principle at work with C/C++'s macro system vs. D's
type-safe compile-time features.  Instead of having a separate
preprocessor complete with its own macro language for fiddling with the
program text, use the D language itself to describe and manipulate D
language structures (alias, static if, enums, templates, etc.). In fact,
marry alias, static if, etc., to CTFE, using basically the same syntax
as runtime D code (with minor distinctions), to get a well-integrated
whole that operates in all 3 domains at once.  Now *that's* empowerment.

Contrast that with the C++ situation where the preprocessor is a
separate sublanguage layered on top of the surface syntax, and
compile-time code needs constexpr littered all over the place with many
arbitrary limitations on what can/cannot be done, all distinct from
runtime code.  There's at least 3 separate sublanguages here with
artificial walls between them. No wonder it takes an expert 10 years to
navigate all the linguistic red tape just to get the simplest of tasks
done.

Now don't get me wrong, D isn't completely free of such artificial
boundaries either, but it's a lot less than in C++.  Metaprogramming in
D is a pleasant walk in the park, as opposed to a strenuous mind-racking
exercise in frustration.


[...]

 I am sorry C++ has so many bright people like Jason Turner in its
 grasp.  Jason Turner has been evangelizing "constexpr everything", not
 realizing that would make the keyword effectively a whitespace word,
 which would mean the need for the constexpr keyword is dubious. (Hint:
 D does not have such a keyword.) Despite appearances, C++ is a net
 loss to humanity. All those bright people could be spending their time
 actually solving engineering problems instead of finding brilliant
 workarounds to C++'s deficiencies.


It seems to be a common malady when working with C/C++: you spend LOT of
time fiddling with little details and wrestling with the language,
rather than making progress in your problem domain. I may be trying to
write a web client, for example, and about half of my time would be
spent not on solving issues and making progress with web programming,
but on fiddling with memory management, chasing down pointer bugs,
grappling with C++'s hideous template syntax, and avoiding language
minefields (double- and triple-checking my loop indices for off-by-1
errors, ad nauseaum).  But man it feels good when I finally overcome
these language barriers (ha!) and invent clever solutions to work around
them -- even though I may have hardly made any progress in my problem
domain (writing a web client).

Like a cool-looking futuristic power drill with hundreds of fancy knobs,
you spent 50% of your time tweaking this and turning that but after 2
hours you haven't begun to drill any holes yet.  Whereas the poor sod
next door uses this unpopular bland-looking drill and has already
finished his job before you've even begun yours.



 To respond to another point in this thread, I am not embarrassed to
 admit that I am emotional. I actually like to be emotional. Thank you
 very much!  :)


Rationality is overrated.  Human beings are more than just rational
thinking machines, emotions are an essential part of being human too.
:-P


[...]

 I regret even attempting to defend D's GC to enlightened (!) C++
 people. I used to be one myself. Now I simply solve problems with D
 and have fun doing it. The GC just works. How about redirecting some
 of the energy people put into C++ to learning different memory
 management strategies...


What about using a language where you don't have to flip bits on
magnetic media with a hand-held magnet (figuratively speaking), but
focus on, y'know, solving the problem you originally set out to solve?
:-D


[...]

 PS: I'm a ESL


 
 Me too.
 

 sorry for any English mistake.


 
 You are doing everyone a favor by writing in English. Thank you! :)


[...]

Walter has said before, and I agree, that often ESL speakers communicate
much more clearly than native speakers who assume you would Just
Understand(tm), without making any effort to make themselves clear.
Ironically, the former apologize profusely for their clear
communication, but the latter feels no remorse for miscommunication.
;-)


T

-- 
"Real programmers can write assembly code in any language. :-)" -- Larry Wall
Mar 10 2022
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 10 March 2022 at 20:25:12 UTC, H. S. Teoh wrote:

 


`D` has no `C++`'s collapse expression.
And It is orthogonal to the '[]' index. Why not add it in d?
`...` Folding expression, is very powerful.
With its help, they can complete powerful metaprogramming like d.
Mar 10 2022
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Mar 11, 2022 at 01:35:46AM +0000, zjh via Digitalmars-d wrote:
[...]

 `D` has no `C++`'s collapse expression.
 And It is orthogonal to the '[]' index. Why not add it in d?
 `...` Folding expression, is very powerful.
 With its help, they can complete powerful metaprogramming like d.


I'm not the one you have to convince; talk to Walter or submit a DIP.
:-)


T

-- 
Food and laptops don't mix.
Mar 10 2022
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 10 March 2022 at 18:47:51 UTC, Ali Çehreli wrote:

 To respond to another point in this thread, I am not 
 embarrassed to admit that I am emotional. I actually like to be 
 emotional. Thank you very much! :)


Well, I've never been emotional in these forums, except when some 
people recently objected to a no-war icon. I showed the icon to 
my daughter and told her that "when it matters technologists 
seize to be narrow-minded and see the bigger picture", then the 
disappointment in the D community's 
the-lets-not-take-a-stance-on-even-the-most-obvious-attitude 
surfaced and I had to apologise to her and let her know that the 
narrowmindedness of technologists actually is deep, they are 
usually not very good at seeing the bigger picture.

The only interesting thing about this thread in relation to C++ 
and constexpr is this: they have a process. When they add a new 
feature they introduce it in a minimal state, then wait for users 
to gain experience with it and extend bit by bit in subsequent 
versions. This is true for constexpr, coroutines and many other 
features.

This brings some advantages:

1. You are less likely to have to revert a design (which is a big 
no-no in C++).

2. Implementors can move in lock-step so that you have complete 
implementations after ~1 year across compilers (usually).

3. You can collect problems users experience and change course 
before you extend the feature.

4. The community needs time to figure out how to make good use of 
a feature, which is needed in order to come up with sensible 
extensions of the feature.

5. You can focus your expenses on things that there is a strong 
demand for and evolve in many directions concurrently.

This is all in line with good language evolution policies. D has 
string mixins and they require compile time string concatenation, 
without string mixins the demand for dynamic compile time string 
concatenation is not very high in the context of system level 
programming. So it made sense to first support a fixed container 
like array (high demand because of LUT building), wait with the 
addition of basic_string/vector to C++20, then we'll have to see 
if there are further improvements in C++23/26. I personally only 
need constexpr array in C++, and more frequently end up with my 
own string representations anyway (typical of lower level 
programming).

If you plan on using C++ for higher level programming than 
dsp/engines you'll be disappointed, but that disappointment goes 
much deeper than any individual feature. C++ cannot become a 
glorified scripting language, nor should it try to be. It should 
focus on the strong points it has, and so should D.

But D needs to learn something about process from C++. Take a 
step away from the 
the-lets-not-take-a-stance-on-even-the-most-obvious-attitude, get 
some clear focus and make priorities. You actually have to choose 
between:

1. slow conservative language evolution based on demand with no 
breaking changes

2. experimental language evolution based on creativity with 
breaking changes

D's current approach is "experimental language evolution based on 
creativity without breaking changes" and that is not a 
sustainable model in the long term.
Mar 11 2022
prev sibling next sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 10 March 2022 at 02:01:01 UTC, matheus wrote:

 Hi,

 Today someone sent me this video: 
 https://www.youtube.com/embed/ABg4_EV5L3w
 (C++ Weekly - Ep 313 - The `constexpr` Problem That Took Me 5 
 Years To Fix!).

 It's a 26 minute long video of a guy trying to generate a 
 concatenated string during CT in C++.

 I was flabbergasted by the problems this poor guy had in front 
 of him for a thing that shouldn't seem so complex (In my 
 opinion of course). And more yet that he has being struggling 
 with this for 5 years.

 So I decided to try the same with D, it was 14 lines[1] of code 
 written in less than a minute and it just worked on the first 
 try. Then I looked the Assembly code:

 .L.str:
         .asciz  "hello world, hello world, hello world, "

 After that I even asked over the D IRC channel if it was just 
 this? And a user confirmed that my string was being generated 
 through CT as the Assembly indicated.

 Again incredible. My first programming language was C, then in 
 2000-ish I had my first contact with C++ and I just hated and 
 went back to C and then while looking for alternatives I 
 stumbled on D which I use till this day as a "super C".

 But now after so many years I couldn't believe the C++ is still 
 struggling even to this day with this type of thing.

 I'd like to quote this comment from the video:


 meowsqueak:
 "Well done solving this puzzle, but I’m left in shock. The 
 need to employ a template, static constexpr variables, a 
 lambda function, and four utility functions just to 
 compile-time generate a static string in C++ is an 
 embarrassment."[2]


 And indeed it is an embarrassment. Well D may have it flaws but 
 I always found it lot time better or less restrictive language 
 compared to others, especially C++.

 Finally I'd like to take this moment and thank for all the 
 effort.

 Matheus.

 [1] - Here is the snippet I wrote: 
 https://godbolt.org/z/MsT36Prx4
 [2] - Youtube comment: 
 https://www.youtube.com/watch?v=ABg4_EV5L3w&lc=Ugzb7kTLS8GNS9bK07F4AaABAg

 PS: I'm a ESL, sorry for any English mistakes.


`~`
Mar 10 2022
prev sibling parent reply IGotD- <nise nise.com> writes:
On Thursday, 10 March 2022 at 02:01:01 UTC, matheus wrote:

 Hi,

 Today someone sent me this video: 
 https://www.youtube.com/embed/ABg4_EV5L3w
 
 [...]


Another thing that kept agonizing me during this video is how the 
author use and mixed std::string and std::string_view. Having two 
containers doing functionally the same thing is insane.
Mar 10 2022
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 10 March 2022 at 20:31:55 UTC, IGotD- wrote:

 On Thursday, 10 March 2022 at 02:01:01 UTC, matheus wrote:

 Hi,

 Today someone sent me this video: 
 https://www.youtube.com/embed/ABg4_EV5L3w
 
 [...]


 Another thing that kept agonizing me during this video is how 
 the author use and mixed std::string and std::string_view. 
 Having two containers doing functionally the same thing is 
 insane.


They aren't the same thing, std::string_view is a string slice 
that doesn't own the pointed data, while string owns the data and 
is responsible for its deallocation, their memory usage is 
definitely not the same and matter a lot in a language with 
manual memory management.
Mar 10 2022
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 3/10/22 3:31 PM, IGotD- wrote:

 On Thursday, 10 March 2022 at 02:01:01 UTC, matheus wrote:

 Hi,

 Today someone sent me this video: 
 https://www.youtube.com/embed/ABg4_EV5L3w

 [...]


 
 Another thing that kept agonizing me during this video is how the author 
 use and mixed std::string and std::string_view. Having two containers 
 doing functionally the same thing is insane.
 
 


It's because std::string_view doesn't manage its memory. If std::string 
worked at compile time, he would have just done that.

std::string_view is the equivalent of D's string, it has a pointer and 
length. std::string is the equivalent of the nefarious GC array 
management mechanism that has no type or name, but works great at both 
runtime and compile time.

-Steve
Mar 10 2022
parent IGotD- <nise nise.com> writes:
On Thursday, 10 March 2022 at 20:44:11 UTC, Steven Schveighoffer 
wrote:

 It's because std::string_view doesn't manage its memory. If 
 std::string worked at compile time, he would have just done 
 that.

 std::string_view is the equivalent of D's string, it has a 
 pointer and length. std::string is the equivalent of the 
 nefarious GC array management mechanism that has no type or 
 name, but works great at both runtime and compile time.

 -Steve


In practice you can make std::string work similar to the strings 
in D, it's just a matter of choice. I think std::string was 
previously reference counted but they went away from that. 
Another reason is that in std::string, NUL is currently always 
added at the end. The c_str() method is a bit guilty of that even 
if it is possible to make the conversion lazy. It's just a 
cascade of bad design decisions that made C++ end up with 
string_view.

I like the strings in D which are miles better and we also see 
how this design decision was the right one (which several other 
languages also did).
Mar 10 2022