>>You may still USE "&cName" - the quotes will do it. > >I tried this and it works....which I find a little incredible.
I remember I was shocked when I discovered that.
>Usually, quotes are the sacred gardians of literal, not to be interpreted by any man or beast, text. Here we have an operator interpreted inside of quotes.
Incredible, isn't it? Yet it works that way, and still we can find good use for it.
>What's really amazing is that if cName is undefined, the result of ?"&cNAME" is the literal string &cName whereas if cName is a string valued variable set to "ON", ?"&cName" produces ON.
Well, I guess once you get past the first shock, this comes sort of logical. It interprets it if it can, leaves as is if it can't.
>There doesn't seem to be a mechanism for preventing "&cName" from being expanded as a macro if cName is defined and contains a string. Ambiguous code is possible.
Therefore you need a good naming convention - you surely wouldn't want to have something like &The in the text, and sleep tight being sure you don't have the="yet another" anywhere in the source :).
>Seems like an ill-designed feature to me.
Actually no, it's cute, and powerful, once you get used to it. I don't remember too many occasions when you'd naturally put an ampersand not followed by a space in any sort of normal text. Writing code generators, which should generate code which uses macros, you may get into some nice gotchas if both the generator and the generated source use a variable with the same name, and it gets macro expanded during generation time, instead of runtime... but that's the only gotcha with this I had in ten years of using macro expansion.
