Commit
Introduce KALEIDOSCOPE_API_VERSION
- Loading branch information
There are no files selected for viewing
3 comments
on commit 086b16f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this helps a bit: https://github.com/pfultz2/Cloak/wiki/Is-the-C-preprocessor-Turing-complete%3F
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cited from the page linked above:
Why is this important? Well when a macro is scanned and expanding, it creates a disabling context. This disabling context will cause a token, that refers to the currently expanding macro, to be painted blue. Thus, once its painted blue, the macro will no longer expand. This is why macros don't expand recursively. However, a disabling context only exists during one scan, so by deferring an expansion we can prevent our macros from becoming painted blue.
It explains why str()
and xstr()
are required to stringify.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Guys, both of you need to take a step back. I'm going to be deleting some replies in this thread as off-topic.
I know I've been an absentee project lead for the last 6 or 7 weeks. I'm really sorry about that. Between baby and shipping and unavoidable travel, I've had my hands more than full. I'm going to try to keep more on top of things.
It's a hack. We have
KALEIDOSCOPE_REQUIRED_API_VERSION
, a#define
, which resolves to a number. In thestatic_assert
, we want to use it as part of a string, so we have to stringify it somehow. We can't use# KALEIDOSCOPE_REQUIRED_API_VERSION
, because that would stringify the macro name, not its value. So we use this double-macro trick, to expand the version macro first, then stringify it.Yes, it is ugly, but it works.