Paul Mensonides wrote:
[...] That is what I mean by pathological input, and you can pass it at any level of scanning. Lastly, some arguments are untyped an have no restrictions at all--including pathological input. These are a precious few, however--e.g.
OK. Definition understood.
I'm interested in writing compiler independent portable C++ code that works in practice ;-)...
Then I'd avoid directly using those macros. They are perfectly legal, but even though they should work portably and consistently, they don't.
<snip>
No, it is more like how a particular sequence of tokens is constructed. I'll try to explain what I'm referring to better... Say you have some token sequence '()' and you pass it to IS_NULLARY, which ultimately results in '1' (as it should). Say then you have some other macro M that ultimately results in '()'. You test this macro, and it works. The you try IS_NULLARY(M()) and that works. Then, you have yet another macro N that also ultimately results in '()' (and it does what it should), but when you try to pass it to IS_NULLARY(N()) it suddenly doesn't work--and not because of particular names being disabled (i.e. it works fine on a conformant preprocessor). It is suddenly related to *how* a particular sequence of tokens is constructed. Some preprocessors seem to do things in strange orders or delay doing certain things until they *think* the results are necessary as some sort of optimization. Because the assumptions about how these changes will affect accurate preprocessing results are wrong, it causes all kinds of problems. That is *precisely* the problem with these macros on several popular preprocessors.
So things may break (for odd reasons) if the macro arguments are in turn macros. Guessing from the Boost.Preprocessor source IS_*ARY seem to /basically/ work unless I'm using Borland. So if the input is intended to be fed by the user directly (without more layers of PP metaprogramming or any macros in it) things would be considerably safe, wouldn't they?
Take a look at 'cat.hpp'. [...]
Aha - interesting! I've been wondering what this code does before... So it's about stabilizing the expansion order.
Be warned--the implementation of much of Chaos is extremely complex. It isn't difficult to use (in most cases) however. The parts where it can be difficult to use are the parts that are exposed as interfaces that allow users to construct components similar to those provided by the library itself. I.e. the philosophy is something like, "If component XYZ is generalizable enough to be used by the library itself in multiple places, then it should be exposed as a proper interface so that client code can use if desired."
Sounds like these parts will probably be the most fascinating ones to explore. The code looks extremely beautiful, but I hadn't had the time to decode all the idioms involved to really understand it, yet ;-(. Thanks again for your reply. If there was a "most informative list member award" you'd be most certainly one of the top candidates ;-). Regards, Tobias