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 ?
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