Date: Sat, 30 Jan 2021 16:27:26 +0100
On Sat, Jan 30, 2021 at 4:19 PM Arvid Norberg via Liaison <
liaison_at_[hidden]> wrote:
> On Sat, Jan 30, 2021 at 2:56 PM Uecker, Martin via Liaison <
> liaison_at_[hidden]> wrote:
>
>> Am Donnerstag, den 28.01.2021, 22:48 +0100 schrieb Martin Uecker:
>> .
>> >
>> > > > 3. And finally there is the problem that C++ does not
>> > > > have them.
>> > >
>> > > Once upon a time, the C++ committee spent quite some effort
>> > > on integrating VLAs.
>> > >
>> > > The history section in this paper
>> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0785r0.html
>> > > is probably a good start.
>> >
>> > Thanks.
>>
>> I tried to look deeper on this, but to be honest I did not
>> fully understand why this went nowhere in C++.
>>
>> To me VLA in C seem conceptually quite simple and powerful.
>> I use them a lot in numerical code and they are extremely
>> useful. There are theoretically sound (in contrast to some
>> other language aspects related to UB) and also reasonably
>> easy to implement in compilers (I did this myself last
>> year in my toy C compiler). So why not just take the
>> C feature as is?
>>
>> It would be helpful if someone could summarize the problems
>> that make it difficult or undesirable to integrate this
>> fully into C++.
>>
>
> I wasn't around when this was discussed in the C++ committee, but I
> suspect these are some of the questions that need answers for VLAs to make
> it into C++:
>
> template <typename T>
> void v(T&& a) {
> std::cout << typeid(T).name() << '\n';
> }
>
> template <typename T, size_t N>
> void t(T (&a)[N]) {
> std::cout << N << '\n';
> }
>
> void u(std::span<int> a) {
> std::cout << a.size() << '\n';
> }
>
> int const len = 10;
>
> void m(int n) {
> int a[n]; // VLA
> int b[len]; // normal array
>
> std::array<char, sizeof(a)> a2; // ERROR: sizeof() is a runtime value
> on VLAs
> std::array<char, sizeof(b)> b2; // OK
>
> std::array<decltype(a), 5> a3; // ERROR: decltype() on VLA
> std::array<decltype(b), 5> b3; // OK
>
> v(a); // ERROR: no matching function for call to 'v(int [n])'
> v(b); // OK
>
> t(a); // ERROR: variable-sized array type 'long int' is not a valid
> template argument
> t(b); // OK
>
> u(a); // ERROR: could not convert '(int*)(& a)' from 'int*' to
> 'std::span<int>'
> u(b); // OK
> }
>
> I think a more practical approach in C++ would be something like:
>
> template <typename T>
> std::span<T> alloca<T>(size_t n);
>
It is probably a stupid question, but, do we not that that VLAs in C++
could lead to additional security issues and vulnerabilities caused by hard
to handle stack overflows?
>
> --
> Arvid Norberg
> _______________________________________________
> 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/0271.php
>
liaison_at_[hidden]> wrote:
> On Sat, Jan 30, 2021 at 2:56 PM Uecker, Martin via Liaison <
> liaison_at_[hidden]> wrote:
>
>> Am Donnerstag, den 28.01.2021, 22:48 +0100 schrieb Martin Uecker:
>> .
>> >
>> > > > 3. And finally there is the problem that C++ does not
>> > > > have them.
>> > >
>> > > Once upon a time, the C++ committee spent quite some effort
>> > > on integrating VLAs.
>> > >
>> > > The history section in this paper
>> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0785r0.html
>> > > is probably a good start.
>> >
>> > Thanks.
>>
>> I tried to look deeper on this, but to be honest I did not
>> fully understand why this went nowhere in C++.
>>
>> To me VLA in C seem conceptually quite simple and powerful.
>> I use them a lot in numerical code and they are extremely
>> useful. There are theoretically sound (in contrast to some
>> other language aspects related to UB) and also reasonably
>> easy to implement in compilers (I did this myself last
>> year in my toy C compiler). So why not just take the
>> C feature as is?
>>
>> It would be helpful if someone could summarize the problems
>> that make it difficult or undesirable to integrate this
>> fully into C++.
>>
>
> I wasn't around when this was discussed in the C++ committee, but I
> suspect these are some of the questions that need answers for VLAs to make
> it into C++:
>
> template <typename T>
> void v(T&& a) {
> std::cout << typeid(T).name() << '\n';
> }
>
> template <typename T, size_t N>
> void t(T (&a)[N]) {
> std::cout << N << '\n';
> }
>
> void u(std::span<int> a) {
> std::cout << a.size() << '\n';
> }
>
> int const len = 10;
>
> void m(int n) {
> int a[n]; // VLA
> int b[len]; // normal array
>
> std::array<char, sizeof(a)> a2; // ERROR: sizeof() is a runtime value
> on VLAs
> std::array<char, sizeof(b)> b2; // OK
>
> std::array<decltype(a), 5> a3; // ERROR: decltype() on VLA
> std::array<decltype(b), 5> b3; // OK
>
> v(a); // ERROR: no matching function for call to 'v(int [n])'
> v(b); // OK
>
> t(a); // ERROR: variable-sized array type 'long int' is not a valid
> template argument
> t(b); // OK
>
> u(a); // ERROR: could not convert '(int*)(& a)' from 'int*' to
> 'std::span<int>'
> u(b); // OK
> }
>
> I think a more practical approach in C++ would be something like:
>
> template <typename T>
> std::span<T> alloca<T>(size_t n);
>
It is probably a stupid question, but, do we not that that VLAs in C++
could lead to additional security issues and vulnerabilities caused by hard
to handle stack overflows?
>
> --
> Arvid Norberg
> _______________________________________________
> 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/0271.php
>
Received on 2021-01-30 09:27:39