Menu
▾
▴
#3 the CXX_HAS_BUGGY_FOR_LOOPS workaround is buggy
the workaround is this:
#define for if(1) for
now consider this:
if (...)
for (...) {
}
else {
...
}
if the workaround is enabled, the else branch never
gets executed.
i personally consider the above code bad style, since i
prefer to _always_ put the conditional part in {}'s,
even if it's just a single expression.
anyway, since this kind of code can happen (as did for
me and wasted a few hours of mine debugging), i bet one
should not use the workaround, rather put the for loops
in {}'s w/ ifdef's or move the loop variable
declarations outside. that's more work, but that will
not fail.
regards, petschy
Logged In: YES
user_id=67568
I agree, we can change that, but what exactly is your suggestion? Give a
#warning?
Logged In: YES
user_id=1203107
unfortunately, i can't think of anything as simple as a
define. the scenarios:
- i is declared outside the for loops, or the for loop has
it's own scope by explicit {}'s : both comilers -> OK
- buggy compiler compiles two for (int i ..) loops in the
same scope -> error at the second loop : i already defined
- buggy compiler compiles for (int i ..) and for (i ...) in
the same scope -> OK
- std compliant compiler compiles two for (int i ..) loops
in the same scope -> OK
- std compliant compiler compiles for (int i ..) and for (i
...) in the same scope -> error at the second loop : i undefined
there is no way to put two symbols with a single
preprocessor token to two different places.
the only solutions i can think of right now:
- move the loop variable declarations outside
- embed the for loops in {}'s
- abandon one of the compilers
unfortunately, both of these methods require to change the
source at every for loop involved, which could be tiresome.
but this is necessary, if want to support both kind of
compilers.
if the developer supports both compilers, then we may
provide some macros like
CXX_BUGGY_FOR_LOOP_BEGIN
for (int i...) { ... }
CXX_BUGGY_FOR_LOOP_END
and they are set to { and } on buggy compilers, and empty on
std compl. compilers. but since this method requires a lot
of typing, the developer is probably better off by simply
writing literal {}'s at the offending places, because extra
{}'s don't make much of a difference i bet (i have no idea
whether the std compl.compiler allocates a new 0 length
frame or not).
so there's no silver bullet. the best we can do is offer the
developer a choice: if he wants to declare his sources as
- compiler neutral (variables declared outside or using {}'s)
- requiring buggy for scoping
- requiring decent for scoping
this shoud go to an AC_/LF_ macro maybe, which
at the end calls the for loop scoping test, and decides
whether the sources may or may not be compiled, and notifies
the user.
what do you think?