6/29 I can't remember a bit of C syntax. I have funtion foo that
returns a value that I need to put in a variable. If that value
is not Null, I want to take some action. Will this work?
int bar = 0;
if(bar = foo())
do something;
\_ Someone should save this for the Classic Trolls Of All Time Hall
Of Fame. I wish I had thought of something so simple as asking
an arcane C syntax question. --lesser troll than op
\_ Maybe you should try an obscure Perl question.
\_ How about:
if(foo()) {something;}
\_ foo() can return NULL, so it's returning a pointer. Therefore
bar should be a pointer. Probably it's a char* pointer. So:
char* bar = NULL;
bar = foo();
if (bar != NULL) { // Do something. }
, or, if (!bar) { // Do something.} (but I like the previous one)
\_ The null pointer is just an integer equal to zero. If the
declaration of foo is 'void foo()' then 'if(foo())' will fail.
The NULL pointer evaluates to false.
\_ op said he wanted to store the value of foo() in a variable,
and also wants to check if it is NULL. (This is common for
text-parsing functions.) Hence the code.
\_ 1. if the declaration of foo is "void foo()", it can't even
return anything, and "if(foo())" won't even compile. What are
you trying to say?
2. There is nothing in the C specification that says NULL is
necessarily 0. Its value is implementation dependent,
although in almost all implementations it's 0.
\_ Not exactly. The preprocessor symbol NULL is guaranteed to
be 0, but it's not necessarily an integer type (it may be
defined to be (void*) 0). NULL is not the same as the "null
pointer"; the compiler transforms 0 in pointer contexts to
the appropriate null pointer, which may not necessarily be
all-bits-zero. --jameslin
\_ The answer is yes. The syntax is:
if (bar = foo())
| \_ Assign 'bar' to be the return value of foo().
|
\_ The value passed to 'if' is the result of the assignment, which
is the value of 'bar'. Any non-zero integral value will
evaluate as true.
\_ "if (bar = foo())" will work, but the compile will probably try to
be nice and warn you that you might have mistyped "=" when
you really wanted "==". To avoid such a warning, you can do
"if ((bar = foo()) != NULL)". With compilers these days, it'll be
optimized the same way as "if (bar = foo())" anyway if the value of
NULL is 0.
\_ And this compiler should be promptly thrown in the trash. In
over 10 years of C/C++ development, I've only been bitten by this
once or twice. Having to munge my code to avoid spurious
warnings only helps newbies who should quickly exit the rank of
newbie anyway.
\_ Isn't this based on the assumption that NULL == 0 or
some equiv. There is nothing in the standard (AFAIK)
that requires this.
\_ No. When a pointer converts to an int, it must convert
to 0 if it is NULL, regardless of the actual bit pattern
of the pointer.
\_ ic. tnx.
\_ Chill down. The compiler gives a warning, not an error.
\_ Spurious warnings make it difficult to find real problems.
Many software shops have a rule of compiling with no
warnings and no errors, so warnings are a problem anyway.
\_ Having to munge your code for spurious warnings is
a bad thing. However, I challenge your determination
that this particular one is spurious. I would want
all my developers to NEVER have an "if (bar = foo())"
statement. That's IMO, anyway. They can still do
it if they want; I wouldn't complain too much if
following the rule affected their productivity, what
with good people being hard to find.
\_ How many more coding guidelines do you want checked
in your compiler? Check it in lint instead. Why
should I have to avoid legal code because *your*
software shop doesn't like that? It's a common
idiom, and it takes all of 5 seconds to learn it.
\_ I don't think you really read what I wrote.
I believe if you got into a meeting with the
top 5 coders in your organization, they would
agree "if (bar = foo())" is bad form, but they
wouldn't bash it over your head, which is what
I've been saying. (Of course you can use whatever
you like if you're not working with other
programmers.)
\_ I did read what you read. Your complaint is
one of style, which is not what a compiler
should check--or at least the complier should
have a way to turn off all stylistic warnings.
\_ I agree with you that the user should be
able to turn off "stylistic warnings".
\_ You want to throw gcc in the trash?
\_ I was grateful of compiler warnings when I had a very sloppy
programmer working on my team. Eventually he was let go after
one year.
\_ Which is the right thing to do with sloppy programmers:
teach them or fire them. |
http://csua.com/feed/