ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
in your if statement you are not comparing(i.e a==1), you are actually testing the success of the assignment functions mapped to the operators =, and += respectively. As a result, unless something is wrong with your ram, they will always *return* true, but will actually assign those values to a,b,and c, causing the output to be always be displayed as "a=0 b=4 c=4".
in your if statement you are not comparing(i.e a==1), you are actually testing the success of the assignment functions mapped to the operators =, and += respectively. As a result, unless something is wrong with your ram, they will always *return* true, but will actually assign those values to a,b,and c, causing the output to be always be displayed as "a=0 b=4 c=4".
That isn't true. The return value of an assignment is the new value of the variable.
Kevin Barry
Okay, just to be completely pedantic, it isn't a 'return' value (which is reserved for functions), but simply the evaluation of an expression. The value of an assignment expression is the value assigned to the lvalue on the left hand side of the assignment operator.
What mf93 said is just not even close to any part of the C language.
The OP's sample code looks like homework, and paulsm4 has correctly seized on the essence of the question.
MF93 pointed out that this is one of the most notorious pitfalls of C. C does not distinguish a boolean type. In C, any nonzero integer is true. Using assignment operator "=" instead of comparison operator "==" as a logic parameter in a conditional expression will always be true unless the assigned value is zero. This can cause hidden bugs which pass program testing and are detected after the program is delivered to the end user. The compiler can generate warnings for this syntax. Setting all warnings as errors in the compiler and editing the source code to clear all warnings can prevent this bug.
This "pitfall" is also a very powerful technique. There are perfectly legitimate reasons to WANT to a) do an assignment, b) treat the result as a boolean, and perhaps even c) string several of these expressions together.
The lesson to be learned isn't to AVOID it. But rather, to UNDERSTAND it. And, of course, to exploit this feature whenever/wherever applicable
This "pitfall" is also a very powerful technique. There are perfectly legitimate reasons to WANT to a) do an assignment, b) treat the result as a boolean, and perhaps even c) string several of these expressions together.
The lesson to be learned isn't to AVOID it. But rather, to UNDERSTAND it. And, of course, to exploit this feature whenever/wherever applicable
Couldn't agree more. I like to use this feature, and do so often. It bothers me that modern compilers seem to assume that I've done so erroneously, and by default flag it as a warning that I have to specifically over-ride.
--- rod
Okay, just to be completely pedantic, it isn't a 'return' value (which is reserved for functions), but simply the evaluation of an expression. The value of an assignment expression is the value assigned to the lvalue on the left hand side of the assignment operator.
Sorry, I was thinking in C++ where operators are functions and assignments return lvalues.
Quote:
Originally Posted by ArthurSittler
MF93 pointed out that this is one of the most notorious pitfalls of C. C does not distinguish a boolean type. In C, any nonzero integer is true. Using assignment operator "=" instead of comparison operator "==" as a logic parameter in a conditional expression will always be true unless the assigned value is zero. This can cause hidden bugs which pass program testing and are detected after the program is delivered to the end user. The compiler can generate warnings for this syntax. Setting all warnings as errors in the compiler and editing the source code to clear all warnings can prevent this bug.
I think you mean "will always be the assigned value" since not just any non-zero value results. Ultimately if ((a = 4)) becomes if (4), which meets the condition of "trueness".
Code:
a = b = c = 4; /*<-- this sets all three to '4'*/
a = (b = (c = 4)); /*<-- also sets all three to '4' (same thing made explicit)*/
I'll chime-in with a politely dissenting opinion, if I may.
I've spent most of my ~30 year career as a consultant in the literal sense of the word. It's not quite that "I pick up the pieces where other programmers and projects have screwed-up things royally," but, well, it is pretty-damm close to that. And so I have seen a lot of "clever" code like that, and I have rewritten a lot of it.
A favorite saying is, "at 3 billion ops a second, no one can hear you scream." CPUs today are unbelievably fast ... but there is also a subtle and therefore often-overlooked reason why they are so fast: the compiler. Processors like the x86 have highly "pipelined" architectures and lots of very-strange instructions. Intel and AMD work hand-in-hand with compiler writers (and publish their own compilers) specifically so that code will be generated, and generated "in the right way," to fully exploit the architecture ... which is designed to be fully-exploited by code that has been generated "in the right way."
So, here's my simple advice: don't be clever ... don't even try anymore. Especially if the compiler is issuing a warning or informational message, pay attention to that message and do whatever you have to do to make that message go away. Your code should compile clean: no errors, no warnings, no hints.
And of course there is another, even more compelling reason: code that is "clever," that therefore cannot be "instantly and accurately read and understood by a distracted human being at first glance," is absurdly expensive. Sure, it might over the course of your entire lifetime save as much as one tenth of one second of actual wall-time, but the cost of a bug or the cost of difficulty in maintenance is beyond calculation. Thousands of dollars. Millions. No kidding.
Make your code "stupid-easy to read." Your compiler will thank you (and will work magic on your behalf). Your colleagues, employers, and customers will thank you even more.
WARNING: THIS POST HAS BEEN WRITTEN BY SOMEWHAT OF A C N00B
I've found that evaluating the "success" or "failure" of an assignment operation (i.e. zero or non-zero assignment) can be useful in checking the return value of a function that returns NULL on error:
I find MrCode's code perfectly readable, and fully acceptable C idiom. Modern compilers and sundialsvcs seem to differ.
I would differ on the use of terms such as success/failure to describe the assignment. The assignment always succeeds, or the computer is broken. The assignment constitutes an expression, which, depending on the context, evaluates to a boolean. The 'success/failure' aspect may be a condition of the function call, again depending on context.
--- rod.
I don't think of it as a way to cleverly try to optimize code, but as a simple, readable way of doing things that would be much more complicated if "=" was not an expression.
I think the argument sundialsvcs is trying to make is that expressions like the one in my example code above aren't "stupid simple to read" and should thus be avoided, and preferably replaced with something like this:
While it's more "readable" (for a given definition of "readable"), it isn't as concise/compact IMO. Of course, something like this (from K&R, according to Wikipedia):
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.