Date: Tue, 10 Mar 2020 00:21:52 -0700
On Mon, Mar 9, 2020 at 10:25 AM Jens Gustedt via Liaison <
liaison_at_[hidden]> wrote:
> Hello,
> I have to say I would not much be in favor to have that feature in C,
> usually people try to make the fact that something is a pointer very
> visible in C.
>
By indicating 'p' on the member/variable names perhaps? after 30 years in
C, and 5 in JS, I really find that the idea that a thing is a pointer vs an
instance of a thing is only a detail that the language MAKES the developer
be aware of. In reality, the programmer just wants to get the value of a
member from an object; and whether that object is statically defined or
pointed to by a variable is really fairly inconsesquential.
It only took MS until 2015 to implement C99; it'll be a whole generation
before this could really catch on.
>
> But then also:
>
>
> > C++ Standard section 8.5.1.5 Class member access
> > add:
>
> > if the first expression of (dot) is a pointer [to an object], then
> > E1.E2 is converted to (*(E1)).E2 .
> Doing like this would certainly be the wrong way for C.
>
I split the gists
C++
gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da#cxx-standards-proposal
C
https://gist.github.com/d3x0r/a574459e4ad18ea1e10a2367b06bd257#c-standards-proposal
The C standard just words it as
--- standard quotes
6.5.2.3 Structure and union members
constaints
1) The first operand of the . operator shall have a qualified or
unqualified structure or union type, and the second operand shall name a
member of that type
2) The first operand of the -> operator shall have type ‘‘pointer to
qualified or unqualified structure’’ or ‘‘pointer to qualified or
unqualified union’’, and the second operand shall name a member of the type
pointed to.
semantics
4) A postfix expression followed by the -> operator and an identifier
designates a member of a structure or union object. The value is that of
the named member of the object to which the first expression points, and is
an lvalue.83) If the first expression is a pointer to a qualified type, the
result has the so-qualified version of the type of the designated member.
16) (cut, about flexible array member) ... However, when a . (or ->)
operator has a left operand that is (a pointer to) a structure with a
flexible array member and the right operand names that member, it behaves
as if that member were replaced with the longest array (with the same
element type) th ...
83) If &E is a valid pointer expression (where & is the ‘‘address-of ’’
operator, which generates a pointer to its operand), the expression
(&E)->MOS is the same as E.MOS.
--- end quoting
so, the intent appears to make everything behave like -> in the C
standard? E.MOS into (&E)->MOS
whereas the working in the C++ standard makes everything behave like '.' .
E1->E2 into (*E1).E2
There isn't really a whole lot of definition about how to implement the
above; and the -> operator appears very few times in the C standard...
> The two operations `E1->E2` look very similar `(*(E1)).E2` but are not
> the same, in particular when evaluated in a thread context. The first
> is an lvalue that is guaranteed to only access the member, where the
> second forms the `*E1` object as a whole, and so may race with
> accesses to other members of the same object.
>
Except, they are both 'get the member E2 from E1' , which really makes them
entirely the same.
A thread context... this doesn't change anything about volatile members...
And there's nothing that -> or '.' themselves helps or clarifies with
threads... in either case they are either referencing a volatile instance,
or volatile member, or volatile pointer to a thing with volatile members,
the proposed modification doesn't change the characteristics of access at
all.
Given thread local declaration which could either be a struct or a pointer,
I don't see how either operator makes thread access apparently more or less
safe; like if I was reading threaded code and saw '->' why would that make
me feel any better about shared access than '.' ?
I might again stress, in a different way, it's about the member in the
object, not the whole object.
>
liaison_at_[hidden]> wrote:
> Hello,
> I have to say I would not much be in favor to have that feature in C,
> usually people try to make the fact that something is a pointer very
> visible in C.
>
By indicating 'p' on the member/variable names perhaps? after 30 years in
C, and 5 in JS, I really find that the idea that a thing is a pointer vs an
instance of a thing is only a detail that the language MAKES the developer
be aware of. In reality, the programmer just wants to get the value of a
member from an object; and whether that object is statically defined or
pointed to by a variable is really fairly inconsesquential.
It only took MS until 2015 to implement C99; it'll be a whole generation
before this could really catch on.
>
> But then also:
>
>
> > C++ Standard section 8.5.1.5 Class member access
> > add:
>
> > if the first expression of (dot) is a pointer [to an object], then
> > E1.E2 is converted to (*(E1)).E2 .
> Doing like this would certainly be the wrong way for C.
>
I split the gists
C++
gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da#cxx-standards-proposal
C
https://gist.github.com/d3x0r/a574459e4ad18ea1e10a2367b06bd257#c-standards-proposal
The C standard just words it as
--- standard quotes
6.5.2.3 Structure and union members
constaints
1) The first operand of the . operator shall have a qualified or
unqualified structure or union type, and the second operand shall name a
member of that type
2) The first operand of the -> operator shall have type ‘‘pointer to
qualified or unqualified structure’’ or ‘‘pointer to qualified or
unqualified union’’, and the second operand shall name a member of the type
pointed to.
semantics
4) A postfix expression followed by the -> operator and an identifier
designates a member of a structure or union object. The value is that of
the named member of the object to which the first expression points, and is
an lvalue.83) If the first expression is a pointer to a qualified type, the
result has the so-qualified version of the type of the designated member.
16) (cut, about flexible array member) ... However, when a . (or ->)
operator has a left operand that is (a pointer to) a structure with a
flexible array member and the right operand names that member, it behaves
as if that member were replaced with the longest array (with the same
element type) th ...
83) If &E is a valid pointer expression (where & is the ‘‘address-of ’’
operator, which generates a pointer to its operand), the expression
(&E)->MOS is the same as E.MOS.
--- end quoting
so, the intent appears to make everything behave like -> in the C
standard? E.MOS into (&E)->MOS
whereas the working in the C++ standard makes everything behave like '.' .
E1->E2 into (*E1).E2
There isn't really a whole lot of definition about how to implement the
above; and the -> operator appears very few times in the C standard...
> The two operations `E1->E2` look very similar `(*(E1)).E2` but are not
> the same, in particular when evaluated in a thread context. The first
> is an lvalue that is guaranteed to only access the member, where the
> second forms the `*E1` object as a whole, and so may race with
> accesses to other members of the same object.
>
Except, they are both 'get the member E2 from E1' , which really makes them
entirely the same.
A thread context... this doesn't change anything about volatile members...
And there's nothing that -> or '.' themselves helps or clarifies with
threads... in either case they are either referencing a volatile instance,
or volatile member, or volatile pointer to a thing with volatile members,
the proposed modification doesn't change the characteristics of access at
all.
Given thread local declaration which could either be a struct or a pointer,
I don't see how either operator makes thread access apparently more or less
safe; like if I was reading threaded code and saw '->' why would that make
me feel any better about shared access than '.' ?
I might again stress, in a different way, it's about the member in the
object, not the whole object.
>
Received on 2020-03-10 02:24:51