Some people suggested to introduce a feature "span" (probably a
type) into C++, so that when one has an int array "a" and calls
"f( a )", the length of a is being transferred to "f", which "f"
is defined using "void f(span<int> a)". The "span" in "f" then
knows the length of "a". This is supposed to be less error prone
than passing a pointer with a separate length argument.
Of course, I immediately wondered whether one could implement
such a "span" for C, and here's a draft:
#include <stdio.h>
#define SPAN_PARAM(x,a,n) x*a,size_t const n
#define SPAN(a) a,(sizeof a/sizeof 0[a])
void print( SPAN_PARAM( int, a, n ))
{ for( size_t i = 0; i < n; ++i )
printf( "%lld: %d\n", i, a[ i ]); }
int main( void )
{ int a[ 3 ]={ 4, 6, 8 };
print( SPAN(a) ); }
. But since C is another language, there are other forces at work,
which means that the overall usability of such macros in C might not
make their definition and use worthwhile. Of course, the "smart" span
type in C++ surely can do more than my simple macros can do in C!
Some people suggested to introduce a feature "span" (probably a
type) into C++, so that when one has an int array "a" and calls
"f( a )", the length of a is being transferred to "f", which "f"
is defined using "void f(span<int> a)". The "span" in "f" then
knows the length of "a". This is supposed to be less error prone
than passing a pointer with a separate length argument.
Of course, I immediately wondered whether one could implement
such a "span" for C, and here's a draft:
#include <stdio.h>
#define SPAN_PARAM(x,a,n) x*a,size_t const n
#define SPAN(a) a,(sizeof a/sizeof 0[a])
void print( SPAN_PARAM( int, a, n ))
{ for( size_t i = 0; i < n; ++i )
printf( "%lld: %d\n", i, a[ i ]); }
int main( void )
{ int a[ 3 ]={ 4, 6, 8 };
print( SPAN(a) ); }
On 22/03/2024 08:30, Stefan Ram wrote:
Some people suggested to introduce a feature "span" (probably a
type) into C++, so that when one has an int array "a" and calls
"f( a )", the length of a is being transferred to "f", which "f"
is defined using "void f(span<int> a)". The "span" in "f" then
knows the length of "a". This is supposed to be less error prone
than passing a pointer with a separate length argument.
Of course, I immediately wondered whether one could implement
such a "span" for C, and here's a draft:
#include <stdio.h>
#define SPAN_PARAM(x,a,n) x*a,size_t const n
#define SPAN(a) a,(sizeof a/sizeof 0[a])
void print( SPAN_PARAM( int, a, n ))
{ for( size_t i = 0; i < n; ++i )
printf( "%lld: %d\n", i, a[ i ]); }
int main( void )
{ int a[ 3 ]={ 4, 6, 8 };
print( SPAN(a) ); }
. But since C is another language, there are other forces at work,
which means that the overall usability of such macros in C might not
make their definition and use worthwhile. Of course, the "smart" span
type in C++ surely can do more than my simple macros can do in C!
(
C++ proposals use new type<T> instead of qualifiers. This creates a big
mess on the type system and incompatibility with C.
I don't have idea how/why they do this constantly.
)
C does not need this for parameters since the current array syntax already cover that.
void f(int n, int a[n])
C already have a syntax for pointer to array
int (*)[2] p;
ram@zedat.fu-berlin.de (Stefan Ram) writes:
Some people suggested to introduce a feature "span" (probably a
type) into C++, so that when one has an int array "a" and calls
"f( a )", the length of a is being transferred to "f", which "f"
is defined using "void f(span<int> a)". The "span" in "f" then
knows the length of "a". This is supposed to be less error prone
than passing a pointer with a separate length argument.
Of course, I immediately wondered whether one could implement
such a "span" for C, and here's a draft:
#include <stdio.h>
#define SPAN_PARAM(x,a,n) x*a,size_t const n
#define SPAN(a) a,(sizeof a/sizeof 0[a])
The usual reason given for writing 0[a] in a macro is so that
parentheses are not needed as they would be (recommended) for *(a) or
(a)[0]. But since you don't seem to care about writing a rather than
(a) I don't see why you wrote 0[a] rather than either *a or a[0].
void print( SPAN_PARAM( int, a, n ))
{ for( size_t i = 0; i < n; ++i )
printf( "%lld: %d\n", i, a[ i ]); }
What happens when print wants to pass 'a' to another function that takes
a span?
Thiago Adams <thiago.adams@gmail.com> writes:
On 22/03/2024 08:30, Stefan Ram wrote:
Some people suggested to introduce a feature "span" (probably a
type) into C++, so that when one has an int array "a" and calls
"f( a )", the length of a is being transferred to "f", which "f"
is defined using "void f(span<int> a)". The "span" in "f" then
knows the length of "a". This is supposed to be less error prone
than passing a pointer with a separate length argument.
Of course, I immediately wondered whether one could implement
such a "span" for C, and here's a draft:
#include <stdio.h>
#define SPAN_PARAM(x,a,n) x*a,size_t const n
#define SPAN(a) a,(sizeof a/sizeof 0[a])
void print( SPAN_PARAM( int, a, n ))
{ for( size_t i = 0; i < n; ++i )
printf( "%lld: %d\n", i, a[ i ]); }
int main( void )
{ int a[ 3 ]={ 4, 6, 8 };
print( SPAN(a) ); }
. But since C is another language, there are other forces at work,
which means that the overall usability of such macros in C might not >>> make their definition and use worthwhile. Of course, the "smart" span >>> type in C++ surely can do more than my simple macros can do in C!
(
C++ proposals use new type<T> instead of qualifiers. This creates a big
mess on the type system and incompatibility with C.
I don't have idea how/why they do this constantly.
)
C does not need this for parameters since the current array syntax already >> cover that.
void f(int n, int a[n])
Although you can't rely on this anymore since it's now an optional part
of the language.
...
C already have a syntax for pointer to array
int (*)[2] p;
I think you mean
int (*p)[2];
Some people suggested to introduce a feature "span" (probably a
type) into C++, so that when one has an int array "a" and calls
"f( a )", the length of a is being transferred to "f", which "f"
is defined using "void f(span<int> a)". The "span" in "f" then
knows the length of "a". This is supposed to be less error prone
than passing a pointer with a separate length argument.
Some people suggested to introduce a feature "span" (probably a
type) into C++, so that when one has an int array "a" and calls "f( a
)", the length of a is being transferred to "f", which "f"
is defined using "void f(span<int> a)". The "span" in "f" then knows
the length of "a". This is supposed to be less error prone than
passing a pointer with a separate length argument.
Of course, I immediately wondered whether one could implement such a
"span" for C, and here's a draft:
#include <stdio.h>
#define SPAN_PARAM(x,a,n) x*a,size_t const n #define SPAN(a) a,(sizeof a/sizeof 0[a])
void print( SPAN_PARAM( int, a, n ))
{ for( size_t i = 0; i < n; ++i )
printf( "%lld: %d\n", i, a[ i ]); }
int main( void )
{ int a[ 3 ]={ 4, 6, 8 };
print( SPAN(a) ); }
. But since C is another language, there are other forces at work,
which means that the overall usability of such macros in C might not
make their definition and use worthwhile. Of course, the "smart" span
type in C++ surely can do more than my simple macros can do in C!
Em 3/22/2024 9:19 PM, Ben Bacarisse escreveu:[...]
Thiago Adams <thiago.adams@gmail.com> writes:
[...]void f(int n, int a[n])Although you can't rely on this anymore since it's now an optional
part of the language.
I think it is back in c23.
But not vlas.
Thiago Adams <thiago.adams@gmail.com> writes:
Em 3/22/2024 9:19 PM, Ben Bacarisse escreveu:[...]
Thiago Adams <thiago.adams@gmail.com> writes:
[...]void f(int n, int a[n])Although you can't rely on this anymore since it's now an optional
part of the language.
I think it is back in c23.
But not vlas.
Correct.
From N1570 (the last public draft before C11):
__STDC_NO_VLA__ The integer constant 1, intended to indicate that
the implementation does not support variable length arrays or
variably modified types.
From N3220 (the first public draft of C26, essentially equivalent to C23):
__STDC_NO_VLA__ The integer constant 1, intended to indicate that
the implementation does not support variable length arrays with
automatic storage duration. Parameters declared with variable
length array types are adjusted and then define objects of
automatic storage duration with pointer types. Thus, support for
such declarations is mandatory.
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Thiago Adams <thiago.adams@gmail.com> writes:
Em 3/22/2024 9:19 PM, Ben Bacarisse escreveu:[...]
Thiago Adams <thiago.adams@gmail.com> writes:
[...]void f(int n, int a[n])Although you can't rely on this anymore since it's now an optional
part of the language.
I think it is back in c23.
But not vlas.
Correct.
From N1570 (the last public draft before C11):
__STDC_NO_VLA__ The integer constant 1, intended to indicate that
the implementation does not support variable length arrays or
variably modified types.
From N3220 (the first public draft of C26, essentially equivalent to C23): >>
__STDC_NO_VLA__ The integer constant 1, intended to indicate that
the implementation does not support variable length arrays with
automatic storage duration. Parameters declared with variable
length array types are adjusted and then define objects of
automatic storage duration with pointer types. Thus, support for
such declarations is mandatory.
Has C23 been ratified yet? The fact that there's a draft of C26
suggests it has been, but the news passed me by.
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:....
Has C23 been ratified yet? The fact that there's a draft of C26
suggests it has been, but the news passed me by.
I don't believe it has.
According to <https://www.open-std.org/jtc1/sc22/wg14/>, "WG14 has
finished revising the C standard, under the name C23".
N3219, published 2024-02-22, is the Draft International Standard.
It's password-protected.
N3220, published the same day, is the C2y draft. My understanding is
that its content is very nearly indentical to N3219. I don't know what changes are possible or likely between N3219 and the upcoming C23
standard.
https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log
N3219, published 2024-02-22, is the Draft International Standard.
It's password-protected.
Sysop: | Tetrazocine |
---|---|
Location: | Melbourne, VIC, Australia |
Users: | 7 |
Nodes: | 8 (0 / 8) |
Uptime: | 130:36:50 |
Calls: | 46 |
Files: | 21,492 |
Messages: | 64,866 |