Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am currently implementing NASM-like preprocessor for my assembler, and I am wondering what is the correct way of handling recursively included files. From what I see, there are two ways to deal with it without hanging the preprocessor or even the OS:

  1. Set maximum include depth.
  2. Disallow including a file recursively (not to be confused with disallowing including a file twice).

Also, as far as I can see, the second approach does essentially the same job, but produces nicer error messages. Compare output of Clang, when compiling file containing #include "main.cpp" only:

In file included from main.cpp:1:
[ repeated many times ]
In file included from main.cpp:1:
main.cpp:1:10: error: #include nested too deeply
#include "main.cpp"

with this (current way of handling this in my preprocessor; input is similar to above, does %include "" at line 6):

In file /home/griwes/projects/reaverasm/tests/ in line 6:
Error: file `/home/griwes/projects/reaverasm/tests/` included recursively.

The approach disallowing recursive inclusion produces - IMHO - more readable output.

The question is: is there any preprocessor technique that would be killed by disallowing recursive inclusion? This question is language-agnostic, so feel free to give examples from any languages.

share|improve this question
Nice question. I immediately fired up my IDE (Delphi2007) to see what that does. It detects the recursion on compile (error) but it still hangs if I open one of the recurring files (takes full CPU on one core) with memory increasing. – Jan Doggen Mar 9 '13 at 19:04
up vote 2 down vote accepted

The Boost.Preprocessor library extends and abuses the C/C++ preprocessor in strange and wonderful ways. One of its features is file iteration, which lets you #include a file multiple times with different macros #define'd each time, and they note that it can be useful (and is supported) for a file to iterate over itself. (Search the examples here for BOOST_PP_IS_ITERATING.) This is an example of (limited) recursion.

share|improve this answer
Oh heck. "Boost.PP [...] abuses" is exactly the way one should call that... – Griwes May 8 '13 at 18:33

I think you're conflating two different things:

  1. Whether to allow recursive inclusion
  2. The error output

I have seen multiple real-world examples where recursive inclusion was desired, but it was usually to work around limitations in the preprocessor. I feel it is wrong to disallow any recursion but a limit of 10 times is reasonable IMO.

share|improve this answer
Well, those two things are quite close to each other; depending on how you handle the recursive inclusion, you either get one error output or another. Also, could you provide some of those examples when recursive inclusion was desired? – Griwes Mar 9 '13 at 17:30

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.