[Development] Fornux C++ Superset

Eric Lemanisser eric.lemanissier at gmail.com
Wed Apr 25 15:45:41 CEST 2018


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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20180425/09332f3b/attachment.html>


More information about the Development mailing list