Fantastic exchange from DConf

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Wed May 10 04:50:32 PDT 2017


On Tuesday, May 09, 2017 07:13:31 Walter Bright via Digitalmars-d wrote:
> On 5/8/2017 1:55 PM, John Carter wrote:
> > On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
> >> Walter: I believe memory safety will kill C.
> >
> > C/C++ has been granted an extension of life by the likes of valgrind and
> > purify and *-sanitizer.
>
> I agree. But one inevitably runs into problems relying on valgrind and
> other third party tools:

> 2. it may not be available on your platform

The fact that it's not available on Windows is extremely annoying. Some
tools do exist on Windows, but you have to pay for them, and in my
experience, they don't work very well. And with my current job, they
_definitely_ don't work, because we mix C++ and C# (via COM). Nothing seems
to be able to handle that mixture properly, and it's _really_ hard to track
down memory problems.

> 4. it's incredibly slow to run valgrind, so there are powerful tendencies
> to skip it

There are cases where you literally _can't_ run it, because it's simply too
slow. For instance, when dealing with live video from a camera, the odds are
very high that under valgrind, the program won't be able to keep up. And if
you're doing something like streaming 16 cameras at once (which happens in
the security industry all the time), there's no way that it's going to work.

Valgrind is a fantastic tool, but saying that valgrind is enough is like
saying that dynamic type checking is as good as compile-time type checking.
It isn't, and it can't be.

So, yes, valgrind can be a lifesaver, but having preventing the bugs that it
would find from even being possible is _far_ more valuable.

That being said, with the push for @nogc and the allocators and whatnot,
we're then once again stuck needing to valgrind D code to catch bugs. It's
still not as bad as C/C++, because the problems are much more restricted in
scope, but avoiding the GC comes at a real cost.

Atila commented at dconf that working with allocators in D code for the
excel wrapper library he had worked on was like he was stuck in C++ again
with all of the memory problems that he had. @safe and the GC have _huge_
value.

- Jonathan M Davis



More information about the Digitalmars-d mailing list