Am Mittwoch, dem 12.03.2025 um 16:20 +0000 schrieb Qing Zhao:
>
> > On Mar 10, 2025, at 15:34, Martin Uecker <uec...@tugraz.at> wrote:
> >
> > Am Montag, dem 10.03.2025 um 15:00 -0400 schrieb John McCall:
> > >
> >
> > ...
> >
> > > That said, my preference is still to just give preference to the field
> > > name,
> > > which sidesteps any need for disambiguation syntax and avoids this whole
> > > problem where structs can be broken by just adding a global variable that
> > > happens to collide with a field.
> >
> > I don't think it is a good idea when the 'n' in 'buf' refers to the
> > previous global 'n' coming before and the 'n' in attribute
> > refers to a member 'n' coming later in the following example.
> >
> > constexpr int n = 1;
> >
> > struct foo {
> > char *p [[gnu::counted_by(n)]];
> > char buf[n];
> > int n;
> > };
> >
> > How are you going to explain this to anyone?
> >
> >
> > And neither global names nor struct members may always be under
> > the control of the programmer. Also that simply bringing
> > a new identifier into scope can break code elsewhere worries me.
> >
> >
> > Finally, the following does not even compile in C++.
> >
> > struct foo {
> > char buf[n];
> > const static int n = 2;
> > };
> >
> > While the next example is also ok in C++.
> >
> > constexpr int n = 2;
> >
> > struct foo {
> > char buf[n];
> > };
> >
> > With both declarations of 'n' the example has UB in C++.
> > So I am not convinced the proposed rules make a lot
> > of sense for C++ either.
> >
> >
> > Disambiguation with '__self__.' completely avoids all these issues
> > while keeping the door open for later improvements.
> >
> > I still think one could use designator syntax, i.e. '.n', which
> > would be clearer and intuitive for both C and C++ programmers.
>
> I think the major reason to use __self.n instead of .n is:
>
> The dot (.) operator, i.e., the member access operator in C, is used to
> access the member of an _instance_ of
> a structure/union.
> We should declare a variable with a structure type first, and then append
> this member access operator to this
> variable and followed by the member name to access the member, and then use
> it in the expressions.
For a designator
struct foo { int n; } a = { .n = 1 };
we also refer to a member 'n' of an instance 'a' of a structure type.
The instance is simply implied by the context.
For
struct foo { int n; char *x __counted_by(.n) };
is also refers to a member of an instance of the struct. The
instance is the 'a' which is later used in an expression 'a.x'
So the instance would again be implied by the context.
So for me this makes perfect sense in both cases (and
for both C and C++)
>
> To me, this is clearer. But I am okay with the designator syntax.
I am also okay with __self__ if people have concerns about
resuing the designator syntax. We could still always drop the
requirement for writing __self__ later.
Martin
>
> Qing
>
> >
> >
> > Martin
> >
> >
> >
> >
> >
>
