On 04/25/2018 12:36 PM, Edward Welbourne wrote:
memory leaks are the most difficult problems to solve.
Well, no, they're not.
I've fixed *lots and lots* of memory leaks.
Some of them were a little tricky: most were trivial.
I can *see* memory leaks just by reading code.
It's one of the reasons code review makes memory leaks rare.
That and nice sensible disciplines like RAII.
Use-after-free is usually harder to solve than a leak.
Deadlocks are almost always harder to solve.
You're right:
1) Deadlocks are much more difficult to find
2) Then comes the use-after-free but they can be easily detected by
throwing an exception with root_ptr
3) Then we have the memory leaks...
You're a smart person there's no doubt about that and I respect that but
people like you aren't cheap either.
- Your salary could easily be up to $300k in New York or San Francisco.
- It's going to take at least 6 months to learn the code base correctly.
- Then you can start doing code reviews once a month for 4 different
authors.
The software I propose is 1% of the price and works right off the bat
with no learning curve for as much authors as you want.
Furthermore wouldn't you rather do "constructive programming" like
coding a solid 3D web engine using WebAssembly or an AI engine than
fixing memory leaks on the iPhone? The industry needs to jump start to
the next level!
Also do you really want to spend time running Valgrind on iPhones or
Androids to find these problems? First Valgrind won't fix the problem,
second it is not giving always the same answer and third it doesn't run
on all embedded devices.
Well, your life is a lot easier if most of your code is cross-platform,
so that your builds for desktop are using most of the same code that
your device builds use; that way, Valgrind testing on desktop will fix
all the memory leaks in the cross-platform code and you only need to
find the leaks in your device-specific code.
The software for radios used by the military for example cannot be
tested on the desktop; it needs to be tested on the device itself.
Furthermore the desktop, the Android and the iPhone don't use the same
memory management so we have flaky results.
Meanwhile, before I'd ever heard of Valgrind, I was hunting subtle
memory abuses on bitty little devices (compared to which Android and iOS
are luxurious palaces) where gdbserver was my friend and judicious
output streamed over netcat helped us to track down what was going
wrong. Leaks were less of an issue than use-after-free and kindred
abuses of pointers. Oh, and image-handling code that assumes it's
running on a little-endian processor.
Luckily gdbserver worked in your case because it mostly always hung in mine.
I believe you over-estimate the difficulty of finding memory leaks, or
of *avoiding writing them in the first place*, which is usually a better
plan. Mature software development teams have solved this problem.
We don't need garbage-collection: we can do it in C++ or C just fine;
it's all a matter of appropriate discipline. Meanwhile, the many other
kinds of bugs may be more troublesome than the authors you quote
understand,
Most of the college graduates these days don't even know C++ very well
because they think it's old fashioned and they don't want to deal with
these types of memory problems. I am offering a solution to this problem
so that the entire industry can focus on efficient "constructive
programming".
And I put Qt on top of the list because you already have all the
necessary layers to jump start to the next level.
Regards,
-Phil
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
