> So isn't that a tool that enforces something upon the programmer?
It's a tool I voluntarily add to my workflow, which works the way I want, when I want, according to project needs. It's not a limitation put upon me by the language/compiler/whatnot.
> What is the benefit of needing valgrind? Isn't it even better to have the task automated away so that the problem doesn't even come up?
In most cases, performance (think of HPC levels of performance). If I don't need that kind of performance, I can just use the stack or smart pointers.
If we're talking about moving to other programming languages, I'd rather not.
> It's a tool I voluntarily add to my workflow, which works the way I want, when I want, according to project needs. It's not a limitation put upon me by the language/compiler/whatnot.
I spent a lot of time maintaining a lot of Perl code. While it was generally very well written, it also made me a big fan of strict, demanding compilers. Perl is quick to write, but can have very high debugging costs since it'll let you get away with a lot that it shouldn't like having a function called with arguments but that completely forgets to retrieve them.
Based on my experience, IMO any class of error that can be eliminated, should be.
So my modern approach is -Wall, -Werrors, -Wextra, and anything else that can be had to that effect, all the time.
It's a tool I voluntarily add to my workflow, which works the way I want, when I want, according to project needs. It's not a limitation put upon me by the language/compiler/whatnot.
> What is the benefit of needing valgrind? Isn't it even better to have the task automated away so that the problem doesn't even come up?
In most cases, performance (think of HPC levels of performance). If I don't need that kind of performance, I can just use the stack or smart pointers.
If we're talking about moving to other programming languages, I'd rather not.