s***@gmail.com
2017-03-26 12:47:21 UTC
So lately I've came up to this again - and to be quite honest recently I've kinda accepted the form f(int a[]) as a shorthand for f(int *a), as part of what the C language is (the same way it was natural for me, before, to know that a file scope declaration using the static storage specifier indicates internal linkage but a block scope one, using the same identifier - storage duration).
However I still don't think this property, this shortcut for writing complex otherwise declarations (imagine if you want to pass a pointer to array) should be something more than this - a shortcut.
What I feel like is that we must banish all other forms except the way an "incomplete array of ..." can be declared as a function parameter to actually mean "pointer to ...". I also feel like we should allow this only in a direct declarator. So for example f(int (a)[]) would be a constraint violation.
The constraint violation should also apply for parameter declarations using a typedef name to specify the array type.
Bottom line:
I see the benefits of using [] as an alternative syntax for * when writing pointer to arrays (useful when passing multidimensional arrays) - consider writing f(int (*p)[2]) vs f(int p[][2]) - (I feel like the second variant is easier to edit.) However I feel like it should be implemented rather as a simple text replacement than whole type system change. Now I know that the preprocessor is another monster but I doubt that implementing a check for direct array declarator of incomplete type will be that expensive to the parser.
I doubt such a change will be any hassle.
The only possible problem I see is if someone has done this:
typedef int tarr[2][2];
int f(tarr par)
{
//... use pointer to multi-dimensional array first element
}
int main()
{
tarr ar; //declare multi-dimensional array
f(ar); //pass pointer to multi-dimensional array first element
}
Because the above can be kinda useful I guess.
If you think that any of the following declarations:
int f(int p[2]), f(int p[*]), f(int p[224]), f(int *p);
as a mean to declare the same type are anything but pure junk - then you may just skip this post and continue writing in C\C++ and may the programming gods be with you.
However I still don't think this property, this shortcut for writing complex otherwise declarations (imagine if you want to pass a pointer to array) should be something more than this - a shortcut.
What I feel like is that we must banish all other forms except the way an "incomplete array of ..." can be declared as a function parameter to actually mean "pointer to ...". I also feel like we should allow this only in a direct declarator. So for example f(int (a)[]) would be a constraint violation.
The constraint violation should also apply for parameter declarations using a typedef name to specify the array type.
Bottom line:
I see the benefits of using [] as an alternative syntax for * when writing pointer to arrays (useful when passing multidimensional arrays) - consider writing f(int (*p)[2]) vs f(int p[][2]) - (I feel like the second variant is easier to edit.) However I feel like it should be implemented rather as a simple text replacement than whole type system change. Now I know that the preprocessor is another monster but I doubt that implementing a check for direct array declarator of incomplete type will be that expensive to the parser.
I doubt such a change will be any hassle.
The only possible problem I see is if someone has done this:
typedef int tarr[2][2];
int f(tarr par)
{
//... use pointer to multi-dimensional array first element
}
int main()
{
tarr ar; //declare multi-dimensional array
f(ar); //pass pointer to multi-dimensional array first element
}
Because the above can be kinda useful I guess.
If you think that any of the following declarations:
int f(int p[2]), f(int p[*]), f(int p[224]), f(int *p);
as a mean to declare the same type are anything but pure junk - then you may just skip this post and continue writing in C\C++ and may the programming gods be with you.