I don't think you should assume that such macro when the expansion list starts with "<" is always only used in #include.

I think it's ugly.. but how about:

#define HDR <10
if (x HDR)

Yes, you're right about this, I have noticed that but I have no idea how to differentiate. Actually both use cases are ugly.

Whether you accept the mod or not, one of these use cases will be interpreted wrongly. I think the one you wrote is rarer as most programmers would prefer to use a function style macro. On the other hand, I don't know the consequences of the false interpretation of your macro - but with my case, the cppcheck analysis of the whole compile unit fails silently because of this, producing an output like a perfect code.

At least when the macro value is simply:

<foo/bar.h>

I think that we can easily put together the tokens in the #include handling.

I don't know if there is some possible filename character that would cause problems.

If the mod should be accepted I suggest to add test case like #116 (comment) (for demonstration purposes as well as for regression test).
Is there a chance to get results from running a modified build on some software set (Linux Kernel, daca2, etc.)? e.g. by comparing the number of errors?

Is there a chance to get results from running a modified build on some software set (Linux Kernel, daca2, etc.)? e.g. by comparing the number of errors?

I think we could look at a modified daca.

To start with if we just grep for #define foo.. <.. in all daca2 packages we can get an idea about how common these macros are and how they are used. I could do that.. but do you feel that you can do it instead?

I could do that.. but do you feel that you can do it instead?
It would be nice if you could do this 😄

I see ~15000 such macros in daca2.

The majority of these macros (replacement list starts with < and macro has no parameters) look like:

#define HDR  <abc.h>

There are ~500 macros that does not match that pattern.. examples:

#define BOOST_TT_TRAIT_OP <
#define _STLP_NULL_TMPL_ARGS <>
#define FORMATTERS << boost::units::raw_format
#define SHIFT <<1
#define IS_A_TERMINAL      <= num_terminals

With this code:

#define X  10
#define HDR  <X.h>
#include HDR

gcc will try to include the file "10.h".

When simplecpp see #include HDR it performs a normal expansion of HDR. That is the proper approach. I believe we should look at how the result can be used properly.

I closed this pull request as the approach is wrong. But feel free to create a new pull request with the right approach.