Is it possible to turn off support for "and" / "or" boolean operator usage in gcc?

Question

GCC seems to allow "and" / "or" to be used instead of "&&" / "||" in C++ code; however, as I expected, many compilers (notably MSVC 7) do not support this. The fact that GCC allows this has caused some annoyances for us in that we have different developers working on the same code base on multiple platforms and occasionally, these "errors" slip in as people are switching back and forth between Python and C++ development.

Ideally, we would all remember to use the appropriate syntax, but for those situations where we occasionally mess up, it would be really nice if GCC didn't let it slide. Anybody have any ideas on approaches to this?

If "and" and "or" are simply #defines then I could #undef when using GCC but I worry that it is more likely built into the compiler at more fundamental level.

Thanks.

Answer 1

Have you considered any code analysis tools? Something similar to FxCop? With FxCop you can write your own rules( check for && ) and you can set it to run during the pre-compile stage.

Answer 2

They are part of the C++ standard, see for instance this StackOverflow answer (which quotes the relevant parts of the standard).

Another answer in the same question mentions how to do the opposite: make them work in MSVC.

To disable them in GCC, use -fno-operator-names. Note that, by doing so, you are in fact switching to a non-standard dialect of C++, and there is a risk that you end up writing code which might not compile correctly on standard-compliant compilers (for instance, if you declare a variable with a name that would normally be reserved).

Answer 3

The words are standard in C++ without the inclusion of any header.

The words are standard in C if you include the header <iso646.h>.

MSVC is doing you no service by not supporting the standards.

You could, however, use tools to enforce the non-use of the keywords. And it can be a coding guideline, and you can quickly train your team not to make silly portability mistakes. It isn't that hard to avoid the problem.

Answer 4

-pedantic-errors may help for this, among other gnu-isms.