John Maddock wrote: [...]
The strange thing is, if I invoke:
C_(5.0, 0e-001)
Then I get:
5.00e-001
And no whitespace anymore!
This leads to me to wonder if GCC is doing something special when it recognizes that the token might be a valid number.... or else that this is just blind luck?
No, that is the way a standard compatible preprocessor works. 0e-001 is parsed as a single pp-token, whereas e-100 is broken down into three pp-token 'e', '-' and '100'. And 1.23e is recognized as a single token, but invalid, because it is not a complete number. The concatenation operator # in BOOST_JOIN concatenates only the two tokens adjacent to it, and the result must be a valid token again. This is why -1234.56 # e-100 does not work: - 1234.56e - 100 are the 4 resulting tokens here, and one of it is invalid. Your idea of using representations of 0 is clever enough to work around this problem. The downside is, that the mantissa receives an additional zero at the end, which is visible in stringizations. It might lead to confusion, when this string is displayed to the user, or an implied precision is derived from it. Cheers Wolf Lammen -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone