[Development] Fornux C++ Superset

[Phil Bouchard]

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
>> fail.
>>>> 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
>> consecutively.
>> 
>> 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"
>> https://www.linkedin.com/pulse/c-hard-find-memory-leaks-vidhut-singh
>> 
>> 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."
>> 
>> https://www.quora.com/How-do-game-studios-prevent-memory-leaks-in-complex-C++-games
>> 
>>> 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
>> class
>>>> names so that their meta-data fits into the top-level namespace but for
>> the
>>>> 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 (
> http://en.cppreference.com/w/cpp/language/nested_types)
> 
> 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.

No:

void foo(int array[])
{...}

void foo(int * array)
{...}

Are the same thing.


Regards,
-Phil