[cfe-dev] [PATCH] add constant expression evaluation to the AST and fix PR2413

Eli Friedman eli.friedman at gmail.com
Sat Jun 14 13:54:33 PDT 2008


On Sat, Jun 14, 2008 at 1:15 PM, Argiris Kirtzidis <akyrtzi at gmail.com> wrote:
> Having a general way to evaluate constant expressions is a great idea and
> very useful for consumers.

Okay, cool.

> However, having
>
> TryEvaluateExprFloat
> TryEvaluateExprComplex
> TryEvaluateExprInt
> ...
>
> doesn't seem to me that it "scales" well. There's going to be a lot of code
> duplication between all those functions

There's a bit of duplication, but they're all working on different
types of data, so it's not that much duplication (for example, integer
addition, pointer addition, float addition, and complex addition all
require different calculations.)

> and there isn't a way for the
> consumer to do action based on the type of the constant:
>
> if (expr is integer)
> ..
> else if (expr is float)
> ...

That doesn't really end up being an issue, I don't think; an
expression of type float can only have a constant of type float, same
for complex float/int, same for pointer, (mostly) same for int.  (The
"mostly" comes from the fact that an int might actually be a pointer
cast to an int; I'll probably end up sending this case through
TryEvaluateExprPtr as a fallback.)

> How about having a single "EvaluateConstantExpr" method, that accepts a
> structure that can hold all the possible values in a union (APSInt, APFloat,
> etc.) plus an enum that can indicate what is the type of the value returned
> (vt_int, vt_float, vt_complex, etc) ?

I was considering that at first... it's a better approach in some
ways, but there's an issue that completely kills this: you can't put
an APSInt or APFloat into a union.  Any suggestions?

-Eli



More information about the cfe-dev mailing list