[Development] Fornux C++ Superset
philippeb8 at gmail.com
Wed Apr 25 14:56:21 CEST 2018
Eric Lemanisser <eric.lemanissier at gmail.com> wrote:
> Le mer. 25 avr. 2018 à 14:03, Phil Bouchard <philippeb8 at gmail.com> a écrit :
>> On 04/25/2018 04:46 AM, Edward Welbourne wrote:
>>> Phil Bouchard (24 April 2018 19:05)
>>>> I’m not sure if you read the link I posted about static analysis but a
>>>> software bug can cause billion dollar projects like space shuttles to
>>>> Maybe MS Word was a bad example but they can be very costly.
>>> The Columbia crash wasn't a (computer) software issue. One can think of
>>> the organisational failure that lead to it as a (human) software issue,
>>> but I don't think we have static analysis software for that. The
>>> closest you'll get is an ISO 9000 compliance auditor.
>>> The Ariane 5 crash was a software error, but it wasn't a memory abuse;
>>> it was using an under-sized integer to hold a value that overflowed.
>>> With luck, static analysis would find that, but it's a pointer abuse.
>>> The loss of the Mars Climate Orbiter involved a software bug, but it was
>>> a wrong choice of units rather than a pointer abuse. Mixing archaic
>>> silly units with sensible SI ones has caused more grief for space
>>> missions than pointer abuses.
>> You need to see the big picture; memory leaks are the most difficult
>> problems to solve. In the labs you stress-test your software for a few
>> days but in real life your software is going to run for a few months
>> I was working for a WebKit-based browser for TVs for a software company
>> and the browser kept crashing after a day of usage because of memory
>> leaks. I mean how are you supposed to watch TV if you need to reboot the
>> set-top box every day at a random time?
>> 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.
>> There is more you can read about the subject here:
>> "Real Production Issue - Hard to find memory leaks"
>> And BTW:
>> "Garbage collection is out the window, because you cannot know when it
>> is going to happen or how long it will take, which leads to stuttering
>> frame rates."
>>> So bugs can have disastrous consequences, sure; but fixing all pointer
>>> abuses won't stop that from being the case. Meanwhile, in the world of
>>> most programmers, most bugs are more or less endurable and most users
>>> would sooner have something that ships today with a few endurable bugs
>>> than not have the software that helps them do whatever it is they do
>>> until someone is sure there are no bugs in it. Buts aren't the only
>>> thing that can cause a software project to fail.
>>>> Also it is possible for me to support nested structures by prefixing
>>>> names so that their meta-data fits into the top-level namespace but for
>>>> moment they’re not. But those are personal preferences like not using
>>>> underscores in function names, etc.
>>> Well, if you can support nested structures, you might have a better
>>> chance of persuading folk to port to your new language; but those with
>>> large code-bases aren't about to re-write them to eliminate nested
>>> structures just because you regard that choice as a personal preference.
>>> I note that Qt has plenty of nested structures.
>>> I'm not volunteering to refactor them away.
>> Support for nested structures is easy to fix and will just take a day or
>> two to do so. For example:
>> struct A
>> struct B
>> Will be converted into the following so that I can have their
>> specialization in a top-level namespace:
>> struct A__B
>> struct A
> This would break existing code, as name lookup from nested class should
> visit first enclosing class before visiting namespace. Also, the nested
> class must have access to all names (private, protected, etc) to which the
> enclosing class has access (
> Since there is no hidden catch then I will tell you right now that:
>> - NULL C pointers will need to be typed
>> - pointer casts to their encompassing structure needs to use
>> _containerof() macro
>> - C-style array parameters needs to be converted to pointers
> What for ? you loose the size information by doing so.
void foo(int array)
void foo(int * array)
Are the same thing.
More information about the Development