Jonathan Wakely wrote:
Because it's valid to do:
struct X {
#include "foo.h"
};
Or even:
struct Y {
#include "bar.h"
where the closing brace is in bar.h
So the compiler can't give an error before the include, because the
header might provide the closing brace.
---
Personally, I would regard those cases as
"less likely" than not, but I admit to being barely (if
that much) at the "above average" level of C++ familiarity.
Would it not be possible to have
some switch that would "assume" control-structures don't
cross included boundaries and could then supply a more helpful
diagnostic? I.e. the default could stay as is, but for those
who try not to have control-structs cross file-boundaries,
such diagnostics are more than a bit "obscure"...
Now that I know about the problem, I can know to
check forward as well as backward from an error, but in some
cases, the forward error may be sufficiently far ahead as
to be rather difficult to find -- or, as in my original make
log -- completely unlisted due to other non-related errors
(no related in the sense that they don't tell me where the
original problem is located).
Would such a switch be possible for projects that could
benefit by such a switch?
Could even add a "#pragma gcc CodeSynced" to
indicate that the code *shouldn't* be in any nested control
structure at that point to allow error diagnostics to be emitted
at the pragma rather than "N" includes away. Dunno if practical
or not -- but I do want to say that
The only reason I suggest a better handling of this error is that
people get used to how helpful the compiler _already_ _is_ with
pointing out errors, so to have it be so 'off' with an error is
"unusual", thus my "extra" confusion...
Tnx..
Linda
