On Tue, Mar 10, 2020 at 6:16 AM Bjarne Stroustrup <bjarne_at_[hidden]>
wrote:

> Shifting to naming conventions would be a sign that a distinction between
> pointers and non-pointers was needed. Using 'p' for pointer names moves us
> in the direction of Hungarian, which was an attempt to compensate for a
> weak type system.
>

I adapted the practice, because then when working with code I wouldn't need
to know the type to know whether to choose . or -> ; hence it was an
attempt to compensate for separate operators to access members; would only
have to know the name of the variable/object member. Such a practice goes
away in C#.

> On 3/10/2020 3:21 AM, J Decker via Liaison wrote:
>
>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__gist.github.com_d3x0r_f496d0032476ed8b6f980f7ed31280da-23cxx-2Dstandards-2Dproposal&d=DwMFaQ&c=u6LDEWzohnDQ01ySGnxMzg&r=-ypbxfA15hWRWp5mAlnCkA&m=WudQBgjM9SNfpIgZCiXa0ysU3mps5BnKdM1mFZa67_U&s=o9Vi23hI4l9PIVDarFCiCipG7b0KOt0lX4J6DXmJqJw&e=>
>
> C
> https://gist.github.com/d3x0r/a574459e4ad18ea1e10a2367b06bd257#c-standards-proposal
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_d3x0r_a574459e4ad18ea1e10a2367b06bd257-23c-2Dstandards-2Dproposal&d=DwMFaQ&c=u6LDEWzohnDQ01ySGnxMzg&r=-ypbxfA15hWRWp5mAlnCkA&m=WudQBgjM9SNfpIgZCiXa0ysU3mps5BnKdM1mFZa67_U&s=f1LajG9ZyolCXP_A5R8U7UsS9-4YKCvS9dR51fKC_n8&e=>
>
>
> 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.
>
>
>>