(Sorry for the double reply back, I should have read ahead). R A <ren_zokuke...@hotmail.com> writes:
> good questions, but i'm surprised that you don't know basic semantics of how > the cpp works. i take it that you don't use it as extensively as others?? Thank for the patronizing words. That is always a good way to get people on your side. > anyways, the c preprocessor DOES understand arithmetic expressions, how else > would conditional expressions evaluate? But it doesn't convert them back to strings. > in regards to floating points and overflows, i would like to remind ian that > floats have never never had to be understood by cpp. yes, there are pragmas > to handle them, but in it's own textual way. that's why you can never use a > float in any conditional directive. defining them on their own, of course, is > permitted, as it gets directly substituted. Are you suggesting that floats not be permitted in the expressions which can be evaluated in your proposed extension? That would indeed simplify matters. > overflows are not an issue. the limit to how large a number can be calculated > by the preprocessor (say for conditionals) is implementation specific, and > yes the C standard does define minimum limits. but after it does all it's, to > the final preprocessed code, it simply substitute the evaluated value (if > we're lucky) or simply substitute an equivalent expression. it's the > compiler's job then to decide how to finally evaluate it, what type size is > it and if it went overflow. basically what i'm trying to say is whatever > value the eval evaluates to, it is always within the bounds of the cpp. you > can then lay the blame on cpp, not the extra eval. Yeah, actually I was wrong here, I see that in C99 (but not C90) the preprocessor types are now specified in target terms. Integers are always intmax_t or uintmax_t. So it would theoretically be possible to specify floating point (if permitted by your extension) as using the target type. I don't know what effect that would have on C99 conforming compilers, possibly none. There would still be an issue with floating point (if permitted) in that it would be necessary to either specify the conversion to string or to accept that the program would differ on different hosts. > it's always easy to get carried away with your emotion when you've been > "outsaid", and in an attempt to redeem oneself, come up with the cleverest > responses that was very little thought of. let's all maintain a good > discussion. Ah, more patronizing words, how nice. Ian
