Talk by Herb Sutter: Bridge to NewThingia

[Dagmar]

On Monday, 29 June 2020 at 21:29:31 UTC, Ali Çehreli wrote:
> Then don't turn it off. :)
>
> I understand there are programs where an undeterministic delay 
> in processing is unacceptable but those programs all run on 
> real-time operating systems anyway, right? ;)
I'm working on virtual audio instruments and effect processors 
and they do their job in real-time. GC is luxury in this context. 
If I switched to D, I'd have to also switch from OOP to simple 
C-like structured programming and implement my own basic set of 
algorithms and data structures.

> OOPS: :) I fail to find a reference table that explains 
> implicitly or explicitly deleted or defaulted fundamental C++ 
> operations like the copy constructor.
I agree, C++ is overcomplicated. That's the reason why I look at 
other languages.

> Yeah, accepting that kind of complexity but rejecting the GC is 
> interesting. (I am not directing this to you but to most C++ 
> programmers.)
Not manual memory management is the main problem in modern C++, 
but its excessive complexity with thousands of nuances that 
simply do not allow you to write a program without hidden issues. 
TBH, I don't suffer bc I have to deal with memory management at 
all. I understand the point of GC advocates, but among other 
things, people choose C++ because it gives them more control. A 
good language should provide the ability to easily ADD a garbage 
collector, not the ability to cut it off, losing a half of the 
language features and its standard library.

> That may be true for many languages but when it comes to 
> getting things done I find D much more productive, manageable, 
> easier, etc. etc. compared to C++. C++ has only one thing over 
> D: Many smart people are already using C++.
D has lots of really interesting features and it's more 
productive than C++, but I find it hard to use in real projects.

> Although I agree that transitive const is the correct feature, 
> I too find it difficult.
Well, I agree that transitive const is a good feature for some 
use cases. For instance, a function may return a pointer to a 
constant linked-list node. In the case of non-transitive const 
you can reach and modify other list nodes through this "constant" 
pointer, which is not good at all. But introducing transitive 
const without showing a way to implement caching, using mutexes, 
etc is not a good idea either. Imagine a class, that protects its 
data with a mutex. How should I implement a getter function 
(const) that locks the mutex? The only way that comes into my 
mind is introducing a global mutex-manager entity that works with 
mutex handles (integers). Any class that requires a mutex would 
call this manager to create a new mutex and remembers its handle. 
This way it can pass this handle to the manager when the mutex 
should be locked/unlocked. But obviously, this is such a horrible 
scheme.

> There is this dated document:
>
>   https://dlang.org/articles/cpptod.html
>
> Although dated, that document should be sufficient to jump to D 
> from C++. :)
Not at all. It's not so hard to learn the syntax and other 
details of a new language. It's hard to adopt it to my needs. 
This document tells nothing about typical issues that C++ 
programmers encounter with when trying to do a real work with D.