[Development] Fornux C++ Superset

[Phil Bouchard]

On 04/24/2018 01:51 AM, Thiago Macieira wrote:
> On Monday, 23 April 2018 22:35:36 PDT Phil Bouchard wrote:
>> On 04/23/2018 10:34 PM, Thiago Macieira wrote:
>>> On Monday, 23 April 2018 18:46:05 PDT Phil Bouchard wrote:
>>>>>> - QML is an interpreted language thus it can be reverse engineered and
>>>>>> plagiarized quite easily.
>>>>>
>>>>> There's a QML compiler.
>>>>
>>>> Which is great but does it compile the Javascript code as well?
>>>
>>> Yes, to an extent.
>>
>> Okay but one way or the other it'll always use the garbage collector as
>> a backend.
> 
> Correct. But that has nothing to do with your argument of reverse engineering.

I am extending my arguments because they weren't well articulated.

>>> My point is: I doubt that you have solved all crashes. You have not. Your
>>> framework may be a huge improvement over a lot of techniques people use
>>> today, but your claims are not believable. You should be more precise in
>>> your wording.
>>
>> Here are the different ways to make an application crash:
>> http://forum.codecall.net/topic/71995-understanding-memory-leaks-and-crashes
>> -in-c/

Here are better summaries:
https://www.ibm.com/developerworks/aix/library/au-toughgame/
https://software.intel.com/en-us/inspector-user-guide-windows-problem-type-reference

> Dereferencing dangling pointers is not the only way to cause crashes. In fact,
> depending on when it happens, that usually has no effect.
> 
> Memory overruns cause way more problems. Your solution won't fix that.

I am trying quickly to find the crash statistics and according to the 
following research: "Memory leaks are one of the primary causes of 
software aging.":
https://www.researchgate.net/publication/319980827_Detection_of_Memory_Leaks_in_CC_Code_via_Machine_Learning

> Use of uninitialised memory almost always causes immediate crashes. Your
> solution won't fix that because, by definition, those cause *because* they
> happened before your solution. There's always more code that you need to
> interface with, so unless you convert EVERYTHING to a safe language (and you
> won't), you won't fix all crashes.

All structures and all atomic types are properly initialized to their 
default values with the parser... even for C apps.

> Crashes also happen because of use of improper instructions. That has nothing
> to do with memory.
> 
>> - The code that was modified by the parser interacts perfectly well with
>> system headers or external libraries that weren't modified at all.
> 
> Which can crash.

There is only 1 std C call that uses malloc() under the hood that is 
problematic, like strdup(), but it is overwritten by the parser. Other C 
calls like printf() are properly handled. Again, worse case you will get 
compilation errors, not run-time errors.

>> The generated code keeps headers that aren't part of your project as
>> include statements so your compiler / cross-compiler will expand these
>> headers normally.
> 
> I can tell you right now Qt is not interested in switching languages.

You mean switching Javascript? I already started working in a compiled 
language to replace Javascript in the past, so perhaps I can resume 
these efforts.

Anyway I have high hopes for Qt as I am using it since January 2000.


Regards,
-Phil