for some reason they blocked my very last email, but i tried CC'ing it again,
maybe this time they'll let it through. i'm forwarding it to you, since we
agree on some points. if it doesn't make it to the mailing list, you might want
to forward it, then... or not.
thnx
----------------------------------------
> From: ren_zokuke...@hotmail.com
> To: david.br...@hesbynett.no; i...@google.com
> CC: gcc@gcc.gnu.org
> Subject:
> Date: Thu, 29 Dec 2011 14:42:08 -0800
>
>
> ok, for typing convenience and that they raise similar questions, i will
> answer them both in the same email.
>
> ----------------------------------------
> > From: david.br...@hesbynett.no
> > You want to allow the evaluation of symbols and expressions by the
> > preprocessor -
> > that means it has to understand the syntax and semantics of these
> > expressions, rather than just doing simple text manipulation. And it
> > leads to more questions when macros and expressions are mixed - when do
> > you do "evaluation", and when do you do simple text expansion? How do
> > you write macros that have the "eval" function in them?
>
> the "eval" directive is nothing more but a proposed name. when a new feature
> is drafted, it gets renamed, say "__eval_value__()", so there is less
> likelihood for a conflict to arise. the possibility of it is still possible,
> but that's the chance you take when you add a new feature. it's been done
> over and over, not only in gcc, but also in standard C.
>
>
> ----------------------------------------
> > From: i...@google.com
> > You are proposing a scheme in which the preprocessor can evaluate
> > expressions and convert them back to strings. What are the types of the
> > numbers in the expressions? What happens when they overflow? If the
> > expressions use floating point values, are the floating point values
> > in the host format or the target format? When converting a floating
> > point value back to a string, what technique is used? Do we want to
> > ensure that all preprocessors will get the same result? Or do we want
> > to use values appropriate for the host? Or do we want to use values
> > appropriate for the target?
>
> ----------------------------------------
> > From: david.br...@hesbynett.no
> > There is no standard environment for C. Should calculations be done as
> > 32-bit integer? What about targets that use 16-bit integers (or even
> > 64-bit integers)? You want to call the function "eval" - what about
> > existing code that uses the word "eval", either as a pre-processor macro
> > or as part of the C code? You want to allow recursive macros - that
> > opens a wide range of problems for getting consistency and clear
> > definitions (and typically requires being able to define macros in at
> > least two different ways - one recursive, one literal).
>
> > I don't expect or want any answers here - I don't think anybody is
> > looking for a discussion aiming to implement the eval idea. I just want
> > to point out that there are many, many questions involved here before
> > anyone could even think about implementing it. And I don't think they
> > could be resolved in a way that is consistent, practical, and adds
> > anything to C or the C pre-processor that is not better handled by an
> > external code generator or an independent macro language. No one wants
> > to re-invent the wheel.
>
>
> 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??
> anyways, the c preprocessor DOES understand arithmetic expressions, how else
> would conditional expressions evaluate?
>
> example:
>
> #define N (A + 3)/2
> #if N < 10
>
> without looking at the implementation details of any specific compiler, this
> inherently necessitates that the cpp inherently understand the meaning --
> it's something fundamental. though by standard, this doesn't necessarily
> substitutes the value of the evaluated N.
>
> 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.
>
> 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.
>
>
> 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.
>
>
>
>
