Date: Thu, 28 Jan 2021 22:24:17 +0100
On 28/01/2021 18.45, Uecker, Martin via Liaison wrote:
> Variably modified types have currently three problems
> which are all fully in the scope of standards bodies:
When reading "variably modified type" above, I'm assuming
you talk about VLAs specifically.
> 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.
> 2. They are incompletely specified and not fully
> integrated into C as types (e.g. one can not store a
> varibaly-modified type in a struct).
There was at least one attempt for this in C++, back in 2014:
http://wg21.link/n3875
(I dimly remember there being other approaches.)
While everybody recognized the beauty of making VLAs
first-class citizens of the type system that would
happily compose via structs, the practicalities
(including considering constructors) meant this
didn't go anywhere.
As far as I understand, VLAs in C do not (and, practically
speaking, cannot) affect static type checking, so we're
looking for a solution that binds "array plus run-time length"
sufficiently tightly to allow runtime checks.
In recent C++, there are many library-provided types / templates
that offer this feature, both owning (std::string, std::vector)
and non-owning (std::string_view, std::span).
In C++20, we've gone to the next step and extended our
algorithms library such that any algorithm that takes
a range of values does so by taking a single "range"
parameter, not two independent "start / end"
(or, equivalently, "start / size") parameters.
Jens
> Variably modified types have currently three problems
> which are all fully in the scope of standards bodies:
When reading "variably modified type" above, I'm assuming
you talk about VLAs specifically.
> 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.
> 2. They are incompletely specified and not fully
> integrated into C as types (e.g. one can not store a
> varibaly-modified type in a struct).
There was at least one attempt for this in C++, back in 2014:
http://wg21.link/n3875
(I dimly remember there being other approaches.)
While everybody recognized the beauty of making VLAs
first-class citizens of the type system that would
happily compose via structs, the practicalities
(including considering constructors) meant this
didn't go anywhere.
As far as I understand, VLAs in C do not (and, practically
speaking, cannot) affect static type checking, so we're
looking for a solution that binds "array plus run-time length"
sufficiently tightly to allow runtime checks.
In recent C++, there are many library-provided types / templates
that offer this feature, both owning (std::string, std::vector)
and non-owning (std::string_view, std::span).
In C++20, we've gone to the next step and extended our
algorithms library such that any algorithm that takes
a range of values does so by taking a single "range"
parameter, not two independent "start / end"
(or, equivalently, "start / size") parameters.
Jens
Received on 2021-01-28 15:24:23