Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
In discussing design possibilities for a project that has a very large number of constants and bit patterns to be defined, the question came up about how many #defines can a standard compiler handle? I assume it is a very large number, but we were curious to know if there is an actual upper bound.
For a “standard compiler”:
5.2.4.1: “Translation limits”
Note the slightly odd way of phrasing the requirement. Implementations could satisfy it by having a single “golden program” which they recognise and compile as a special case, although that would be akin to rigging benchmarks. In practice you can read the standard as saying that if your implementation imposes a limit other than available memory, then that limit should be at least 4095. Beyond 4095 you are relying on implementation-specific behavior to an extent.
Some compilers (Microsoft) impose some implementation limits which are less than the standard says. These are listed somewhere on MSDN I think, but possibly only for C++. As far as C goes, since I’m quoting C99 it might not be relevant to MSVC anyway.
For GCC and MSVC in particular, it shouldn’t be too hard to test whether a given implementation imposes an arbitrary limit, perhaps easier than finding it documented 🙂 Auto-generate files containing nothing but great long lists of
#define, see what the preprocessor makes of them.