[snip]for (x = in_sig->beg_x; x < in_sig->end_x; x++)
for (y = in_sig->beg_y; y < in_sig->end_y; y++)
for (z = in_sig->beg_z; z < in_sig->end_z; z++) {
val = 0;
for (dx = conv_k->beg_x; dx < conv_k->end_x; dx++)
for (dy = conv_k->beg_y; dy < conv_k->end_y; dy++)
for (dz = conv_k->beg_z; dz < conv_k->end_z; dz++) {
val += in_sig->dat[x+dx][y+dy][z+dz]
* conv_k->dat[dx][dy][dz];
}
out_sig->dat[x][y][z] = val;
}
Richard said:There's a way to use sizeof that looks as if it's a function call...
infobahn said:I don't.
You are wrong to infer that. I do in fact understand boolean variables.
I also understand that in almost all cases, foo() does not return a
boolean variable, but an int.
then I am perfectly prepared to write if(foo(bar)) rather than
if(foo(bar) != 0)
But the fact that you find the form "annoying" suggests that you need to
relax a little.
Absolutely. And a boolean variable can only answer one of those
questions, which is why so few of my functions return boolean
variables.
No, it should be obvious to any C programmer worth their pay that
the result of strcmp is not boolean, but relational (negative,
zero, or positive).
We do, however, care whether the result is negative, zero, or positive.
I, however, do not encourage early exit from a function. In all too
many cases, this makes the control flow harder for a maintenance
programmer to follow. Maintenance programmers are often under a lot
of pressure to fix a problem quickly, in code they don't know very
well. Anything we can do to help them out is a bonus, and writing
your functions to have all the structure of spaghetti bolognaise is
not helping anyone.
But nobody has to maintain the code in K&R's book. Also, whilst I
greatly admire both K, R, and their book, the day I use K&R as a
style guide is the day I grow an extra arm.
I am fortunate enough not to have got used to early exit from functions.
I am very happy for you if you are used to it, but I have developed my
own style based on my own reasoning and logic, and I'm quite happy to
use that style.
Your style for you; my style for me.
Oh, I do that already, and have done for many years.
There, I must agree with you. What makes this worse is when foo() is not
a boolean function, and yet its result is still compared against a
"boolean" symbol such as TRUE or FALSE.
Oh, I see. You're complaining against code structure.
I prefer:
if(foo(bar))
{
rc = baz();
}
else
{
rc = NONZEROSTATUSVALUE;
}
return rc;
Do you have a problem with the nesting depth here?
Yes, that's what I thought you meant before.
This code, whilst correct, will have the newbies (and some older hands)
reaching for their K&Rs. Better: c = (a == b);
I would prefer c = (a != b);
I didn't find them particularly funny. Just silly.
Mmmm. Well, just pray you never have to maintain my code.
Not in my newsreader, they aren't.
Well, the compiler doesn't need them. The human sometimes finds them
useful, so I put them in /all/ the time.
For a start, they should be close enough together that you can
see which ones match which other ones.
And even if they aren't,
if you line them up
{
like this
}
you don't have to worry about which ones match which, because it's
obvious.
And even if it weren't obvious, decent modern editors can
whizz you from { to } and back in the blinking of an eye.
E. Robert Tisdale said:Idioms are for idiots!
That's two questions.
Because the result returned by strcmp is not zero
and any non zero result used as a conditional
is [implicitly] converted to true.
Unfortunately, the rest of us must write code
that is obvious to C programmers *not* worth their pay
as well as C programmers who are worth their pay.
This means that I write explicit code
rather than relying upon implicit conversions.
I would write:
if (0 != strcmp(string1, string2))
to detect strings which don't match.
It isn't my responsibility to ferret out incompetent programmers.
Alan Balmer said:But that's just not true, except for the I/O functions. Most others
return some value as a result, not as a diagnostic.
I will write "if (a)" providing 'a' is a boolean.
if (a != 0). If that bothers you, so be it.
Keith Thompson said:Personally, I don't think of the result of strcmp() as a boolean
value. It's effectively a tri-state value, one of <0, 0, or >0
depending on the result of the comparison.
comparison:
if (strcmp(string1, string2) != 0) ...
If the function's name implied that it tests whether the arguments
differ, I might feel differently about it.
YMMV, of course, and any C programmer needs to be able to understand
the use of strcmp() in a condition (though I confess it takes me a
moment of thought).
[...]if(foo(bar) == TRUE) /* where true is a macro defined as some non-zero
value */
{
(indented code for the entire rest of the function)
}
return somestatusvariable;
when it should be
if(!foo(bar))
return NONZEROSTATUSVALUE;
(code for the entire rest of the function now not indented so far)
On this I agree wholeheartedly. Never compare a value to TRUE or
FALSE; if such a comparison makes sense, the value is already a
condition and should be used as one.
(note also that some may have different notions as to what TRUE should be
defined as: -1, 1 etc. which makes the test against TRUE not just
idiomatically awkward, but potentially dangerous.)
Yup.
[...]
if(a == b)
{
c = FALSE;
}
else
{
c = TRUE;
}
which should be
c = !(a == b);
Or
c = (a != b);
(Yes, I like the parentheses, even though they're not strictly
necessary.)
[...]I hope its mindshare is dimishing. I would have written the above as:
if (!cap_issubset(inheritable,
cap_combine(target->cap_inheritable,
current->cap_permitted)))
goto out;
That's indented much too deeply for my taste. Are you using hard tabs
with a non-standard tabstop setting?
I might write:
if (!cap_issubset(inheritable,
cap_combine(target->cap_inheritable,
current->cap_permitted)))
...
[snip]This way arguments to functions are lined up.
--
Keith Thompson (The_Other_Keith) (e-mail address removed)
<http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*>
<http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Christian Bau said:Keith Thompson said:Natt Serrasalmus said:news:[email protected]... [...]
Which "we" are you talking about? It doesn't include me.
I write if(foo(bar) != 0)
I find that form really annoying and when I see it in others code. It
suggests to me that the person who wrote it doesn't understand boolean
variables and the C idiom that was established with the C standard
library.
The idiom I am referring to is that functions should return a value
that
answers the question "Did anything go wrong and if so what was it?". By
that
idiom then it should be obvious to any C programmer worth their pay
that
if(strcmp(string1, string2))
means "Did anything go wrong (not match up) when comparing these two
strings?" (if I wanted to know how far off they were I'd save the
return
value to a variable and evaluate that, but rarely does anyone ever care
how
far off the comparison was, other functions may have more interesting
non-zero return codes.)
Personally, I don't think of the result of strcmp() as a boolean
value. It's effectively a tri-state value, one of <0, 0, or >0
depending on the result of the comparison. I prefer an explicit
comparison:
if (strcmp(string1, string2) != 0) ...
If the function's name implied that it tests whether the arguments
differ, I might feel differently about it.
First, by definition it is a multi-valued function and not a boolean
function.
called it "strcmp" and not "strnotequal" should be shot.
"Natt Serrasalmus said:As I pointed out in other posts, there is no boolean in C. Logical
expressions are evaluated as integers having a value of zero or non-zero.
Natt Serrasalmus said:As I pointed out elsewhere, there are no boolean values in C.
Natt said:Natt said:(e-mail address removed) wrote: [snip]
I write if(foo(bar) != 0)
I find that form really annoying
I don't.
Nothing in C is truly boolean. There is no C type for boolean. There are
only integers that are evaluated in logical expressions to be either zero or
non-zero. While that sounds like boolean values, you are technically correct
in claiming that is not truly boolean, but as far as the C language is
concerned the logical alternatives are zero or non-zero. Notice also that if
you do a logical not (!) on any non-zero value you will get zero. Perform
the same operation on zero and you get a non-zero value.
int func(arglist)
{
(declarations)
void *pointer;
if(!condition1)
return BADSTATUSVALUE:
pointer = malloc(SOMESIZE);
codeline;
codeline; [snip]
codeline;
codeline;
if(!condition2)
{
free(pointer);
return BADSTATUSVALUE;
}
codeline;
codeline; [snip]
codeline;
if(!condition3)
{
free(pointer);
return BADSTATUSVALUE;
}
codeline;
codeline; [snip]
codeline;
if(!condition4)
{
free(pointer);
return BADSTATUSVALUE;
}
codeline;
codeline; [snip][snip]codeline;
while(condition5)
{
long_code_line_that_doesn't_have_to_be_broken;
codeline;
codeline;
codeline;
}
free(pointer);
return GOODSTATUSVALUE;
}
Now then, this second example is far easier to deal with. The extreme
indentation has been eliminated, the distant brace matching has been
eliminated and the retval variable has been optimized away. This results in
several less things to keep track of. With the less indentation, fewer long
lines need to be broken up.
Also consider how the first example reads in the sense of ordinary language:
if condition1 keep going if condition2 keep going if condition3 keep going
etc.
as opposed to:
if not condition1 stop if not condition2 stop if not condition3 stop etc.
This is more consistent with a language that refers to traffic signals as
stoplights not golights.
Natt said:When a logical expression is evaluated in C, it is evaluated as an integer
expression and it determines if the integer is zero or non-zero. Sounds
boolean doesn't it? Two states: either zero or non-zero.
If foo() is truly boolean in nature,
Nothing in C is truly boolean. There is no C type for boolean.
There are
only integers that are evaluated in logical expressions to be either zero or
non-zero. While that sounds like boolean values, you are technically correct
in claiming that is not truly boolean, but as far as the C language is
concerned the logical alternatives are zero or non-zero. Notice also that if
you do a logical not (!) on any non-zero value you will get zero. Perform
the same operation on zero and you get a non-zero value.
I should say that none of your functions return boolean variables since
there is no such thing as a boolean variable in C.
The C language treats the result as a boolean value in a logical context,
it's either zero or non-zero.
Why? Normally, I only care if the strings are the same or not. The distance
between each other is not something I can normally do anything about.
If you think early exits from functions results in spaghetti, then you don't
know what spaghetti is.
From an earlier post:
Consider the (pseudo) code examples below:
retval = otherfunc(whatever);int func(arglist)
{
(declarations)
int retval = BADSTATUSVALUE;
if(condition1)
{
return retval;
}
Now then, this second example is far easier to deal with.
What you wrote should be written as:
return foo(bar) ? baz() : NONZEROSTATUSVALUE;
Why should anyone have to keep track of rc when it is not needed? Why should
anyone have to follow several lines of flow of control when none are needed?
In the code you provided, it is too easy for that harried maintenance
programmer to just stick in trial bits of code inside each of the brace
pairs until they stumble upon something that takes care of the problem,
nevermind that it can create another problem or obscure the purpose of the
code. In the case I provide, the maintenance programmer should have no
trouble understanding the single line of code and if they don't (they
shouldn't be coders for a living), they had better figure it out before they
attempt any modifications. Requiring maintenance programmers to actually
know what they are doing is not a bad thing.
However assuming that you could have provided a more complicated example, I
would have expected it to be similar to the form in the re-posted (pseudo)
code example 1. Having given that example, you should have no trouble seeing
how early exits from functons improve the readability of the code.
If it gets someone reaching for their K&Rs then so much the better.
Touche'.
They should be up to speed on the language.
return (somestatusvariable);
When I see that it makes return look like a function call, which it isn't.
[...] I have had to fix code that follows your
conventions and typically the problem arose from a maintenance programmer
who followed the same conventions and couldn't be bothered to truly
understand what the code was doing. Chances are they were intimidated by the
bulk of the code. So they just stuck a few lines of code in, maybe some
initializers and by a hacking band-aid approach managed to fix the bug they
were assigned to fix. Nevermind that they made the code even worse, even
bulkier and even harder to maintain for the next person.
In mine they were and I used spaces, not tabs.
This human finds them to clutter up the code. I've asked several coders who
adopt your method when braces are necessary and when they aren't. I've never
met one who knew. These are people who are being paid to write C code.
The purpose of the brace is to define the beginning and end of a compound
statement. When you put braces where they are not needed, I read it as the
compiler does as in "open brace: start compound statement" then you put a
single statement where a compound statement is expected. That would be
comparable to putting punctuation in English where none is expected.
(Charlie Brown writes a letter:
Dear, Grandma,
I, had a, nice day, at school, today,. We, studied punctuation, marks.
Today, we, learned about, the, comma,. )
Natt Serrasalmus said:As I pointed out in other posts, there is no boolean in C. Logical
expressions are evaluated as integers having a value of zero or non-zero.
If not, I will write
If a is an integer, then it can have a value of zero or non-zero and
therefore can be treated as if it were a boolean value. Therefore, why go to
the trouble of doing the comparison?
infobahn said:Even before C introduced _Bool, it was possible to use ints (and
other integer types) as Boolean values, by the simple method of only
ever writing a 0 or a 1 to them.
What do you think strcmp stands for? I usually think of it as "string
compare", meaning "do the strings compare?". By that sense, the function's
name implies that it tests whether the arguments differ.
It looked like this when I posted it. I used spaces, not tabs.
infobahn said:You missed my point. Consider the following function names:
int IsPrinterReady(PRINTER *);
int IsLeapYear(int);
int Sum(int *, size_t);
int HasTransferCompleted(DATA *);
int OpenDatabase(DB *);
All these functions return int. It is quite obvious, however, to
the experienced, intelligent, or just plain common-sense eye that
three of the five are designed to answer a Boolean question. That
is, they return a number representing 'true' or a number representing
'false'. The others do not.
You have certainly demonstrated how early exits from functions appear
to encourage long, poorly written, rambling functions.
I agree, but nobody should have to remember precedence tables.
You keep repeating this as if it is something you just learned ;-)As I pointed out in other posts, there is no boolean in C. Logical
expressions are evaluated as integers having a value of zero or non-zero.
If not, I will write
If a is an integer, then it can have a value of zero or non-zero and
therefore can be treated as if it were a boolean value. Therefore, why go to
the trouble of doing the comparison?
[True Style] is a common style, but its mindshare seems to
be diminishing.
I'll believe you, though it saddens me. Pursuing the analogy
with English, frequent misspellings eventually make their
way into the dictionary, but that doesn't make misspelling
right.
The True Style was never universally agreed, of course,
but was in very widespread use among the most elite C
programmers.
Good and bad code may be written in any
style of course, but I'm sure there is (was?) a strong
positive correlation between coding in True Style and
positive traits like clarity and modularity.
(I'm not
saying True Style is intrinsically conducive to good
coding practice, just that those who use it tend to have
learned from or emulate the Masters.)
(1) I was mostly observing this style already, a major
exception being brace placement. I was writing
}
else
{
but in True Style this is written
} else {
The second form is simply better than the first! The former
form disconnects the keyword "else" from both its antecedent
and postcedent
and is distracting to read.
Also it wastes
two lines on the screen compared with the latter form, and this
is a "big deal." The left-braces in Non-true code use up
considerable vertical space and therefore more scrolling is
needed to understand a function. Smaller fonts might alleviate
this problem, but that's not an option for those of us
with poor eyesight.
(2) I was proud to emulate the style of so many Masters.
(3) As I examined various software I noticed the strong correlation
between True Style and good traits like clarity and modularity.
(4) Whitespace arrangement isn't all that important but
uniformity would be convenient.
Richard said:.... snip ...
Oh? We shouldn't remember that * goes above +, and both above &&?
It's not generally necessary to remember the details surrounding
&, &&, = and ==, but I'd certainly want any competent programmer
to remember the basics.
CBFalconer said:As far as I am concerned, multiplicative has precedence over
additive which has precedence over logical will do. Anything
further should be explicitly indicated with the use of the all
purpose parentheses. The mere existence of further levels in C is
a fault IMNSHO. Yes, I know there are no precedence levels in C,
just Backus-Naur descriptions.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.