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
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
