Holy cow, I wrote a book!
In response to my description of how you can
use the #error directive to check
whether the compiler even sees you,
some commenters proposed alternatives.
I never claimed that my technique was the only one,
just that it was another option available to you.
Here are some other options.
Error: Semicolon expected at line 412 of file unrelated.h
After your asdasdasd, all that was generated were a bunch
of #defines, #ifs, #endifs,
None of them generate output, so the compiler proper doesn't see anything;
the preprocessor ate it all.
Finally, at unrelated.h line 412, a header file finally
tried to do something other than just define a macro,
and it's only then that the error is detected.
But if you can pick the new error out of the error spew, then go for it.
(There are also obscure cases where an extra asdasdasd
doesn't introduce a new error.)
Since the string #error is shorter than asdasdasd,
and it works in more places, I just go with #error.
Another suggestion came from
Miguel Duarte who
suggested generating the preprocessed file and studying it.
That helps, but the preprocessor output tends to be huge, and,
as I noted in the base article,
#define directives don't show up, so it can be hard for you
to find your place.
I also noted in the base article that
if you use Visual Studio's
precompiled header files,
the contents of the preprocessed output may not match what the compiler sees.
In fact, that's the most common reason I've found for a line being ignored:
You put the #include directive in a place that the
preprocessor sees but which the compiler doesn't see
because you violated one of the
precompiled header consistency rules,
source file consistency rule.