1

I had to work with legacy code which was overpopulated with macroses by murky C-geniuses over 2 decades ago: it mostly #defines used for emulation of RTTI, generating virtual, non-virtual methods, data members, free functions, code that is describing many kinds of inheritance relations, casts, uncommon looping statestments and so on. #defines are nested. I don't know if it's a matter of taste thing, or habits - but I don't want read, understand, but mostly support and maintain this code. Books about C++ say that macroses should be used rarely and carefully, like goto operator. And I wonder if there is some tool (or compiler option redirecting preprocessor output, or something) that would allow to expand these #define macroses w/o expanding #includes, and maybe w/o touching user supplied filter/list, inside source code. For example (which is just example, I'm ok with common macroses), if I feed this tool with source file containing below code:

#define MAX( a, b ) ( ( a ) > ( b ) ? ( a ) : ( b ) )

int main()
{
    int x = -1;
    int y = 100;

    int max = MAX( x, y );

    return 0;
}

It will output source file with:

#define MAX( a, b ) ( ( a ) > ( b ) ? ( a ) : ( b ) )

int main()
{
    int x = -1;
    int y = 100;

    int max = ( ( a ) > ( b ) ? ( a ) : ( b ) );

    return 0;
}

Or maybe even prettier than previous excessive-parentheses example:

int max =  a > b  ? a : b;

Thanks.

Soup Endless
  • 439
  • 3
  • 10
  • 4
    `gcc -E` will output the preprocessed code. – Eugene Sh. Jun 29 '18 at 18:58
  • 1
    yes `-E` will do – cleblanc Jun 29 '18 at 19:02
  • 1
    Many compilers (not just `gcc`) indeed do have an option to preprocess the source code only, and / or to record or print the preprocessed code in the course of compilation. Be aware that this typically gets you a bunch of code from system headers along with everything else. – John Bollinger Jun 29 '18 at 19:02
  • Have you considered replacing the macros with template functions where possible first? – François Andrieux Jun 29 '18 at 19:02
  • 2
    Not sure how `a > b ? a : b;` is prettier than `MAX(a,b)` – cleblanc Jun 29 '18 at 19:03
  • 1
    @cleblanc I think the comment is saying `a > b ? a : b;` is prettier than `( ( a ) > ( b ) ? ( a ) : ( b ) );`, not `MAX(a,b)`. – François Andrieux Jun 29 '18 at 19:03
  • 2
    @FrançoisAndrieux but surely the prettiest of them all is `MAX(a,b)` no? – cleblanc Jun 29 '18 at 19:04
  • Nothing standard will make it "even prettier" though. – Eugene Sh. Jun 29 '18 at 19:05
  • 1
    The only IDE I know of that does this is Eclipse. It lets you expand macros in-source (or maybe in a pop-out widget, I can't recall). You can have it show you what the macro would expand to. It might even allow you to expand the macro one step at a time. – Justin Jun 29 '18 at 19:06
  • 3
    In many cases you can rewrite rhe macros as simple (constexpr) functions. That would probably be *my* approach. It's not fun, but just do them one by one over a period of time, possibly as "breaks" between other tasks. Eventually you'll have eaten the elephant one bite at a time. – Jesper Juhl Jun 29 '18 at 19:12
  • Switching to preprocessed source will make the code more brittle and harder to understand and maintain. If there is a problem with MAX() it has a single location / definition. If you switch to preprocessed source there might be hundreds of cases of "varx > vary ? ... " with different variable names that are no longer marked as being MAX(). – Dave S Jun 29 '18 at 19:12
  • 1
    That `MAX` is one of the classic bugs `MAX(a++, b)` has comical results. – user4581301 Jun 29 '18 at 19:13
  • ... but MAX(a++, b) is also comically bad coding style so it deserves to fail :) . More seriously, if it was changed to a function instead of macro then every use of it can be fixed at once. Not so with the preprocessed source. – Dave S Jun 29 '18 at 19:16
  • Won't having GCC spit out the pre-processed code also paste in the contents of all the includes? – Christian Gibbons Jun 29 '18 at 19:21
  • 1
    @SoupEndless Unfortunately, there's no good answer here, so you're kind of stuck, and while the comments above didn't come out and say that, they may have seemed somewhat unsympathetic. But of course sympathy won't solve your problem, which is that your project has gotten itself stuck in an all-too-common trap, but one that there's probably no way out of, other than a lot of hard (and manual, or at best semiautomated) work. – Steve Summit Jun 29 '18 at 19:48
  • 2
    The old [C FAQ list](http://c-faq.com/) has [a couple of answers](http://c-faq.com/cpp/unifdef.html), but they're (a) for C and (b) pretty dated. (I don't know if any of those tools exists in usable form today.) – Steve Summit Jun 29 '18 at 19:50
  • @SteveSummit Thanks. – Soup Endless Jun 30 '18 at 11:45

0 Answers0