Julian Elischer schrieb:
Christoph Mallon wrote:
variables. Sorting them in a beneficial way for space efficiency is
better left to them (and it is a rather trivial thing to do). Also you
cannot control if more spill slots have to be inserted or some values
do not live in memory at all, so only the compiler can determine,
which order is best.
But a compiler can do more: It could coalesce the space of variables
with disjoint life ranges. But this is much harder, because you have
to properly determine the life ranges. Finding an arbitrary
overestimation is easy, but the fun starts when looking at called
functions, which get passed addresses of local variables. Also finding
an optimal coalescence for known life ranges is NP-complete in the
general case. But that's another story. (:
re-using space or having block-local variables means that when you
are in the debugger, you can not look at the final value that
a variable had when you left (unexpectedly) the block. This can
be a pain in the neck. (but only a debugging feature)
I'm talking about an optimized build - no matter what the style of the
original source was, you will have a hard time debugging it.
+Prefer initializing variables right at their declaration.
I have gone the other way on this. Unless 'const' is being used I
find I prefer to see them separately initialized.
So you like hunting in multiple places instead of having both type and
value conveniently in one place?
Actually.. yes
So at the one hand you argue that hunting things is bad, but at the same
time you prefer it? I am confused.
unconditional initialization is right at the top, AFTER the blank line.
Conditional initialization must of course come after the condition, and
can not be in the same line as the declaration anyhow.
It is perfectly valid to do so. Warner presented a simple example. You
just have to limit the scope of the variable, which is a good for other
reasons, which were explained, too.
+Do not reuse the same variable in a different context, delare a
new variable.
I buy this largely - though it should be applied with common sense
as usual.
hmm. I think an exception might be made for our old friends i,j,k
Especially they should be declared right where they are needed. C99
even conveniently allows the iterator variable to be declared in the
first part of a for-loop: for (int i = 0; i != n; ++i) { ... }. By
limiting their scope, this prevents accidently re-using stale values
in a different place or other mistakes like the following:
int i, j;
for (i = 0;; ++i) {
for (i = 0;; ++i) {
/* oops, but compiler is happy */
}
}
for (j = 0;; ++j) {
/* more */
}
vs.
for (int i = 0;; ++i) {
for (int i = 0;; ++i) {
/* warning about shadowed variable */
}
}
for (int j = 0;; ++j) {
/* more */
}
while tempting, I can't see that hapenning..
it stops teh following:
for (;;) {
blah
if (foo)
break;
}
if (i == end_condition) {
then we didn't break out;
}
You reject a common case because of one special case? This is sad. (Also
there are multiple ways to resolve this nicely, e.g. split the loop into
a function or invert the condition and restructure the code slightly)
-Use ANSI function declarations unless you explicitly need K&R
compatibility.
+Use ANSI function declarations.
Everyone shuld be doing that already.
In new code, and in old code that they touch.
So, is this pro or contra removing the K&R-clause?
K&R code should be changed as part of related changes if possible.
A sweep to change a whole file is probably also ok.
changing them one at a time is probably not ok.
But this is what actually is practiced.
You still did not answer my question: Do you agree to remove the clause
so no new old style declarations may be added?
Christoph
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
