25.04.2018, 16:46, "Eric Lemanisser" <eric.lemaniss...@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 <philipp...@gmail.com> a écrit : >> Eric Lemanisser <eric.lemaniss...@gmail.com> wrote: >>> Le mer. 25 avr. 2018 à 14:03, Phil Bouchard <philipp...@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@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > , > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
