Talk by Herb Sutter: Bridge to NewThingia
dagmar.zorg at gmail.com
Thu Jul 2 10:13:02 UTC 2020
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
> Yeah, accepting that kind of complexity but rejecting the GC is
> interesting. (I am not directing this to you but to most C++
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
> There is this dated document:
> 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.
More information about the Digitalmars-d-announce