C++ Logo

liaison

Advanced search

Re: [wg14/wg21 liaison] (SC22WG14.18841) [Fwd: sudo buffer overlow]

From: Corentin <corentin.jabot_at_[hidden]>
Date: Sun, 31 Jan 2021 20:49:35 +0100
On Sun, Jan 31, 2021 at 8:43 PM Uecker, Martin via Liaison <
liaison_at_[hidden]> wrote:

> Am Sonntag, den 31.01.2021, 17:37 +0000 schrieb Niall Douglas via Liaison:
> > On 30/01/2021 22:27, Uecker, Martin wrote:
>
> ...
>
> > > If C++ rejects dependent types because C++ people "dislike" them
> > > (as you said above), then your type system will remain limited in
> > > what you could do with it. Of course, external tools could
> > > always attach their own more powerful types to C++ terms, but
> > > the C++ type system could not help.
> >
> > Thanks for all the exposition I didn't reply to in order to keep this
> > reply short.
> >
> > Don't get me wrong here, other C "successors" went the dynamic runtime
> > type route, Objective C being the most obvious, but C# is another famous
> > one. Whilst there is nothing wrong with languages such as Objective C or
> > C#, in my personal opinion I would say that their time has passed
> > relative to better alternatives.
> >
> > I don't want to make too sweeping a statement, but in my experience
> > dynamic runtime types never optimise well. If you write your Python with
> > static types, Pyston will optimise the snot out of it. If you write your
> > Python with dynamic types, Pyston gives up very easily.
> >
> > I'm not a language person, nor a compiler person, but it seems to me
> > that dynamic runtime types do not easily produce bare metal execution
> > performance. I think indirection of dynamic information whilst keeping
> > the top level of the type system 100% static is a better design approach.
>
> I think this is a bit of misunderstanding. What you have
> been describing is that C++ is erasing the length from
> the type and making it a run-time property. But this
> allows for less static type analysis not for more.
>
> A type like
>
> std::span<T>
>
> which is something like
>
> template <typename T>
> struct span {
> size_t len;
> T* ptr;
> };


> erases any information about the length from the type.
> This more like dynamic languages with weak typing and
> the opposite of what C is doing here.
>

FYI, size erasure is the default but it isn't required
http://eel.is/c++draft/views.span#span.overview-2

>
> A regular static array type like T[5] has the full length
> information in the type. A VM type like T[N] in C also
> has the length information as run-time property. But
> it still has static information about this dependency
> in the type. You know for example that T[N] and T[M]
> are compatible iff N == M and you know this conditional
> property statically.
>
> You can easily read form the types, for example, that in
> the following function *a and *b have compatible types:
>
> void foo(int N, double (*a)[N], double (*b)[N])
> {
>
> }
>
> In contrast, if you have
>
> void foo(std::spawn<T> a, std::spawn<T> b)
> {
>
> }
>
> you do not know this statically! So the C approach
> has more information available at compile time - not
> less.


>
> Best,
> Martin
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/01/0284.php
>

Received on 2021-01-31 13:49:49