[Development] Fornux C++ Superset

[Konstantin Tokarev]

25.04.2018, 16:46, "Eric Lemanisser" <eric.lemanissier at gmail.com>:
> What about
> void foo(int (&array)[3])
> and
> template<int N>
> void foo(int (&array)[N]) ?
> Both of these functions make sure the caller and the callee use the same array size at compile time. I don't see anybody giving away this kind of security, especially fro functions called across translation units. Does your system store the length of the array next to the pointer at runtime ? What is the cost of this ?

Also, compiler might do additional optimizations for arrays when everything happens in the same translation unit, or when LTO is used.

>
> Le mer. 25 avr. 2018 à 14:58, Phil Bouchard <philippeb8 at gmail.com> a écrit :
>> 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
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> ,
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Regards,
Konstantin