Sujet : Re: Top 10 most common hard skills listed on resumes...
De : bc (at) *nospam* freeuk.com (Bart)
Groupes : comp.lang.cDate : 13. Sep 2024, 14:18:53
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vc1e3s$s2sa$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
User-Agent : Mozilla Thunderbird
On 12/09/2024 21:51, Keith Thompson wrote:
Bart <bc@freeuk.com> writes:
On 12/09/2024 20:38, Keith Thompson wrote:
Bart <bc@freeuk.com> writes:
[...]
It's not that complicated, not with C anyway.
Agreed. Let's stop doing that. (Your specific statement that there are
*four* categories triggered a lot of the "too much".)
I actually said 3-4 categories, depending on when index operations get turned into pointer operations. In C source they don't, but it might conceptually be in the mind of whoever is writing the C source.
Upthread, you wrote:
That's the only thing that needs to 'change', which I don't think is
onerous anyway.
Would you like to clarify what you think needs to change?
That was in reply to this (I've capitalised 'changing'):
WH:
>"To be more precise, gcc parser when seeing a variable
creates read reference to this variable. When parser realizes that
already recognized part of expression is the left hand side of an
assignment it converts it to write access. So your approach is
no worse than gcc. But it creates troubles, process of CHANGING
subexpression with read references into write access is more
complicated than replacing read instruction by write instruction."
I put my 'change' in quotes since I didn't believe any such change is necessary. But if somebody or something deems it so then, in C, that would only apply to one lvalue on the LHS of an assignment.
WH was criticising the approach of initially dealing with LHS/RHS, lvalue/rvalue, the same way, then making any 'changes' later.
I gave an example of a LHS that might appear in some languages that had MULTIPLE lvalue terms on the left of an assignment, that could be nested within a complex expression, where that appoach gives very little trouble.
But I can see you're mainly concerned with scanning my posts to see if there's any divergence from the exact wording of the C standard, even though the discussion is a little wider than that in crossing language boundaries, and includes implementation details that are beyond the scope of the standard anyway.
All I can say is that comp.std.c is that way --->