The main problem with C macros is their usage when a regular function would do just fine. That goes for a lot of the cruft in the Windows headers. Having said

The main problem with C macros is their usage when a regular function would do just fine. That goes for a lot of the cruft in the Windows headers. Having said that, while I object to most ideas that "C is missing", I do think that better constant expressions and expression macros (functions on the syntactic-expressions level) would be a usability improvement in APIs compared to (token stream) preprocessor macros. Even though in the presence of the preprocessor, constants and expression macros would be somewhat redundant. One advantage of expression macros is that you do macro expansion after parsing to an AST. You get a valid AST parse with macro expansion if and only if you get a valid parse without expansion. Expression macros are regular AST elements, and are scoped just like regular functions or variables. They don't have a weird textual scoping scheme with conditional compilation or un-/redefinability. Getting rid of that should make it easier to translate them to other languages. Another advantage is that they allow you to actually know which constructs in an interface are part of the API. An expression macro is always supposed to be used directly by the consumer of the API, or at indirectly through another macro that is. That particular problem of the C preprocessor could in fact be solved if headers cleaned up after themselves, but in practice, preprocessor is just to messy so nobody does that.