Re: Regarding assignment to struct

On 29/05/2025 14:49, Andrey Tarasevich wrote:

On Wed 5/7/2025 12:37 AM, David Brown wrote:

>
That would get an immediate downcheck during review for exactly
that reason.

>
Of course.  In fact, if someone presented such code for review (and assuming I noticed the commas!) I'd have to consider whether it was done maliciously, intentionally deceptively, due to incompetence, or smart- arse coding.  In all my C coding experience, I can't recall ever coming across a single situation when I thought the use of the comma operator was appropriate in the kind of code I work with.

 Wow! That's catastrophically bad.
 As it has been stated many times before, both C and C++ are programming languages that embrace both statement-level and expression-level programming. Expression-level programming (e.g. where `?:` is used for branching and `,` for sequencing) is a very valuable and massively important programming paradigm in these languages. The fact that elaborate expression-level programming is not in nay way abandoned or shunned today is pretty obvious in C++, since C++ took major steps lately to develop its expression-level capabilities. But it has always been and will always remain important in C as well.

No, expression-level programming has always been and will likely always remain a very minor part of C programming.  Yes, some people make use of the comma operator.  Some people do so extensively - and they are often, but not necessarily, considered "smart-arse" programmers rather than "smart" programmers.  If the comma operator were removed from the C language, I guess some 95% of programmers would barely notice - at worst, they would have to add an extra line inside an occasional "for" loop.  (The tertiary operator is used much more.)
I did not say that the use of comma operators is always bad - I said I do not recall seeing it in the kind of code I work with in a situation where I thought it was a good way to write the code.  A significant part of that is the kind of code I work with - in code for small systems where high reliability and safety is vital, code clarity is of utmost importance.  Code that does not do what it first appears to do is severely frowned upon.  Code is written in a very imperative style.
In my world, code that uses "malloc" is rarely acceptable, and for most programs, "double" is very seldom an appropriate choice of type.  But that does not mean these are not usable for other kinds of C programming.  There are many reasons why different styles of coding are used in different circumstances.
Even when C++ is used, with its significantly broader support for a variety of programming paradigms, I do not recall seeing the comma operator used.

 The proclivity to stick exclusively to statement-level programming in C and, God forbid, impose it in others through so called "code reviews"... that would be a trait specific to "sweatshop" development outfits, which strive to replace quality with quantity. I'd agree that in a revolving door employment environment relying on a large number of low-competence developers such code might be seen as "too confusing". But I don't see why we should set our standards that low here, in `comp.lang.c`.
 

I don't quite see how you are in any position to judge the coding styles used by people you know nothing about, working in fields that you know nothing about.
I am happy that different types of programming styles and paradigms are used for different purposes - imperative C is not suitable for most coding tasks.  Equally, expression-style programming is not appropriate for all coding tasks.
However, one thing that is never suitable for any real-world programming is deceptive code that is not what it appears to be.