[Development] Fornux C++ Superset

[Phil Bouchard]

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