Re: Top 10 most common hard skills listed on resumes...

Bart <bc@freeuk.com> writes:

On 12/09/2024 00:47, Ben Bacarisse wrote:

Bart <bc@freeuk.com> writes:
 

On 11/09/2024 01:02, Ben Bacarisse wrote:

Bart <bc@freeuk.com> writes:

>

Sorry, did your remark above suggest I don't know what an lvalue is?

That seemed like the obvious explanation for the incorrect information
you gave.  Did you post it /knowing/ what other kinds of things are
lvalues in C just to confuse people?

>
Which incorrect explanation was that?
>
I merely said that LHSs of assigments fall into these categories:
>
    A = Y;         // name
    *X = Y;        // pointer
    X[i] = Y;      // index
    X.m = Y;       // member select

Yes, that incorrect explanation.

>
I dispute that. What I said is very broadly correct. But in this newgroup
you do like to nitpick.

Someone who wants to write p->m = 42 would not consider it nitpicking if
your compiler did not accept that form of LHS.

But I agree I was simply correcting a small error.  Why did you not just
say "yes, I forgot a few cases"?

So to you, it is of the greatest importance that somebody doesn't just know
about those four categories that they will be reading and writing all the
time in C code, but also know about:
>
  (int){A} = Y;

You see why I wonder if you had a political career?  This is pure spin.
There is no technical argument here, just an attempt to mock someone
pointing out a truth.  I never even suggested that it was important,
just that it was a missing case.  And, still spinning away, you ignore
X->m which /is/ important and was also missing.

which they will encounter approximatey never. And it is also vital they
they consider:
>
   (A) = (Y);
>
a distinct category.

More spin.  There is nothing vital about it at all, and no one ever said
there was.  In fact I explicitly stated that I was ignoring such
details.

There might be a case for this for '(Z, A) = Y;' but
that isn't allowed anyway. So it only applies to superfluous
parentheses.

Clearly I mean VALID LHSs, otherwise they wouldn't be LHSs of assignments!
>
I've since learnt about a couple of other possible categories; one is with
compound literals like '(int){42} = 0'.

Along with (a) _Generic expressions (where the selected arm is an
lvalue)

>
>
The _Generic forms reduce down one of those four.

It would reduce down to one of the six or seven (dependin how we want ot
count), not to your four.  Anyway, you were not listing "reduced" forms
but the valid shapes for left hand sides.

It is more like a macro,
and if you're going to start with macros, there are unlimited categories
that can be created. If this is merely about syntax, then why not?
>
(I'd also like to see an actual usecase for _Generic on the LHS of an
assignment. Perhaps one where there is a matching (symmetric?) _Generic on
the RHS?)
>

and (b) expressions of the form X->m.

>
Are there any circumstances where X->m does something different from
(*X).m?

Are there cases where X[i] does something different to *(X+i)?  You felt
the need to distinguish them despite the fact that they are equivalent
by definition.

(I don't count (A), ((A)) etc as a
separate category; come on!)

Don't give me "come on!".  I was counting forms in the same way that you
were when I said I could think of three more.  I was not counting
parentheses.

>
Keith mentioned this form.

Your reply was to me.

The other is 'X.m' but when .m is a bitfield;

What makes X.m = Y, where m is a bitfield, an extra category?  It fits
the X.m = Y pattern perfectly well.
 

although this has the same
same syntax as above, internally it's somewhat different.

Your categories were syntactic.  You were describing forms.

>
Not entirely. There is behaviour associated with them.
>
Most LHS terms can have & applied in an rvalue context for example;
bitfield accesses can't. So it's something a user of the language needs to
know about.

You were describing the forms of assignment.  If you want to consider
"things you can't do with some valid left hand sides", bitfields are not
alone in being special[1], but there is no reason to single them out
when just being left hand sides.

And internally, my ASTs (where bitfields are supported) use a different
node type when X.m is a bitfield rather than a regular access.

[1] in case you accuse me of teasing again, your first form of LHS, A =
Y, can't be the operand of & if A is declared with storage class
register.

--
Ben.